The Social Engineering of Tool Adoption

A Bricks Whitepaper

On the behavioural psychology of changing tools at work — why "dependence" is the wrong word, why downgrades hurt more than upgrades, and why a platform whose AI is an interface (not a runtime) is the only honest answer to enterprise AI adoption.

June 2026

Concept and intellectual ownership: Simon Mulquin. Drafting and research assistance: Claude Opus 4.7 (Anthropic). Published by Bricks.

Executive Summary

A recurring strand of industry commentary in 2025–26 has settled on a particular reading of developers who say they "can no longer do their job" after their employer swaps one AI assistant for another — the canonical example being a migration from a frontier model to a less-capable in-house or vendor-bundled assistant. The dominant register frames this as a moral failing — a dependence to be ashamed of, a generation of practitioners who never learned to code without an LLM, a craftsmanship that has been lost.

This paper argues that the moral reading is wrong, and that getting it wrong has organisational consequences. The developer is not "dependent" on a tool in any clinical or pathological sense, and the systemic sense the framing implies is more nuanced than the discourse suggests. The model itself is not the source of any meaningful lock-in — the AI-API market is competitive and switching one vendor's assistant for another is a straightforward engineering exercise. What is not free is rolling the worker's practice back. Behaviour adapts to a tool over months; rolling that adaptation back — to a less-capable assistant, or to none at all — is an adaptation that takes commensurate time and carries real attrition risk for any business that has not budgeted it. The cost-of-ownership question that follows is therefore not "can we change the model" — we can — but "can we absorb the productivity dip, the slowed business cadence, and the attrition cost on the way through." There is a real systemic risk in this picture; it is not vendor lock-in at the model layer but what happens when a business has wired an AI capability into the critical path of a function and has not paid the practice-rollback bill in advance. This is also the failure mode Bricks has explicitly architected against: AI is offered as a supportive capability on top of a deterministic substrate, never as a critical-path runtime function the platform's customers would be unable to operate without. The developer at the centre of the dominant narrative is exhibiting the entirely predictable behavioural response of a human worker whose tool has been downgraded without the ingredients required for habit change. The behavioural-psychology literature on this question is sixty years deep and remarkably consistent. The literature has names; the discourse rarely uses them.

Two claims structure the paper:

The first claim is psychological. Tooling transitions in enterprise are not a question of whether the new tool can technically do the job. They are a question of whether the organisation has supplied the ingredients required for the people doing the job to change their habits. Knoster's grid (vision, skills, incentives, resources, action plan), Lewin's force-field analysis, Gleicher's formula, Fogg's behaviour equation, and Kahneman and Tversky's loss aversion all converge on the same operational point: a policy change without resources, incentive, and a path is not a transition. It is a downgrade enforced by attrition. We name these frames to point readers at the underlying literature rather than to summarise it; we expect anyone making a real change decision to read past our gloss.

The second claim is architectural, and it is the one Bricks itself stakes its position on. A platform that uses AI as an interface to deterministic substrate — workflow engine, SDK, semantic graph, data-flow registry — is structurally different from a product whose runtime depends on a continuous LLM call. The first can absorb a model change without breaking what was already shipped; the second cannot. Bricks is the first kind. Our growth without AI is linear but assured; our growth with AI is exponential. Only the exponential half is what allows the platform to reach the long tail — the small businesses, associations, communes, and freelancers that GAFAM-priced software has structurally excluded.

The rest of the paper develops these two claims, anchors them in the behavioural-psychology literature by name, and draws the operational consequences for how Bricks onboards new integrators, supports tool migrations inside customer organisations, and positions itself against an AI ecosystem that has spent eighteen months conflating "AI adoption" with "AI replacement of work people used to know how to do."

Pillar 1 — Dependence is not the right word

The prevailing framing — "a developer who depends on their AI assistant" — collapses two distinct phenomena: runtime dependence (the work cannot proceed at all without the tool) and behavioural attachment (the work can proceed, but the cost of doing it the old way is now much higher than it used to be). The two require different interventions and tell different stories about the worker. A useful sharpening is to note that even the dependency that does exist sits at a different layer than the framing implies — at the practice layer, where habit-rollback is slow and expensive, not at the model layer, where vendor swaps are routine engineering. Conflating the two is what makes the question look like a worker-discipline problem when it is really an organisational-budget problem.

Nobody depends on a shovel to dig a hole. You can dig with your hands. But take an excavator operator and ask them to dig the same hole with a shovel, the shovel with a spoon, the spoon with their hands, and you will get the exact reaction the prevailing commentary mocks — and you will get it from a worker who is not weak, not pampered, and not lacking fundamentals. They are exhibiting the predictable cost of having had their tool surface contracted without any of the ingredients required for the work to be re-organised around the contracted surface.

A job is not an activity for which you swap the tool. A job is a practice — a learned organisation of attention, memory, vocabulary, habits, identity, and professional self-image around a particular tool surface. Tools shape the practice; practices accumulate inside the worker. The honest psychological vocabulary for what the developer at the centre of these stories is describing is not "I cannot work without this tool" but "the energy required to do this work with the new tool is materially higher than it used to be, and my employer has not supplied me with the ingredients to absorb that cost."

This is the same vocabulary the behavioural-psychology literature has used for sixty years to describe organisational tool changes, regardless of whether the tool is a piece of software, a manufacturing process, a clinical protocol, or a healthcare-records system. The next two pillars name the relevant frames.

Pillar 2 — The ingredients of change: Knoster

The most widely-used diagnostic frame for tool transitions in enterprise comes from Timothy Knoster's model of complex change (developed in the 1990s with Villa and Thousand, building on Lippitt's 1958 Dynamics of Planned Change and Lippitt's own descent from Kurt Lewin's group at the Research Center for Group Dynamics). It identifies five ingredients that must be present simultaneously for a change to succeed: vision, skills, incentives, resources, and an action plan. The model's diagnostic value is its inverse — when an ingredient is missing, the failure mode is predictable and named:

The grid is diagnostic precisely because it does not reduce to one root cause. Most failed enterprise tool transitions exhibit two or three missing ingredients at once, and the resulting behaviour in the affected population is a compound of the corresponding failure modes — anxiety overlaid on resistance, frustration overlaid on confusion. The developer at the centre of the prevailing narrative is exhibiting the textbook combination of missing skills (the new tool's affordances unlearned), missing incentives (no personal payoff for relearning), and missing resources (no training time, no productivity-dip tolerance). The signature the commentary mocks — anxiety, resistance, frustration — is exactly what Knoster's grid predicts when these three are absent at once. The discourse reads it as a character defect; the grid reads it as three missing inputs.

The operational implication is that a tool transition in enterprise is a budget question, not a discipline question. The five Knoster ingredients are each a line in the budget the change program must fund: vision is a communication line, skills are a training line, incentives are a compensation line, resources are a productivity-dip line, the action plan is a project-management line. When any of the five is unfunded, the corresponding failure mode appears in the affected population on schedule. Pretending otherwise is the modal posture of the AI-adoption discourse in 2025–26, and explains a great deal of the attrition that discourse produces.

Adjacent academic literatures arrive at the same operational conclusion through different vocabularies. The clinical-and-health-behaviour-change tradition has the COM-B model and the Behaviour Change Wheel (Susan Michie, UCL) — useful as a higher-altitude summary that captures the same constraints under three headings (Capability, Opportunity, Motivation). We mention it for readers who want to enter the academic literature from that side; we do not treat it as the primary frame for enterprise tool transitions, because it abstracts away the per-ingredient diagnostic specificity that makes Knoster's grid operationally useful at the budgeting level. Readers tempted to stop at the COM-B summary should follow the Behaviour Change Wheel down into the underlying intervention-mapping work, where the per-mechanism specificity returns.

Pillar 3 — Forces and thresholds: Lewin, Gleicher, Fogg

A second tradition in the same literature focuses less on ingredients and more on forces and thresholds — what has to be added, removed, or multiplied for the equilibrium of behaviour to actually shift.

Kurt Lewin's force-field analysis is the foundational frame. Developed in the 1940s within Lewin's broader field theory of social psychology, it models any current state of behaviour as a quasi-stationary equilibrium held in place by two opposed sets of forces: driving forces pushing toward change and restraining forces holding the current state in place. The temptation in change management is to focus only on driving forces — to "sell" the new tool harder, to make the announcement louder, to brand the program. Lewin's empirical observation is that this typically raises tension without producing change, because the restraining forces rise in proportion. The more effective intervention is usually the inverse: weaken the restraining forces. Identify what is making the current behaviour easy and remove it, before, or alongside, adding pressure toward the new behaviour. The corresponding three-stage sequence — unfreeze → change → refreeze — is widely-cited and often shallowly summarised. Lewin's actual point was that the unfreeze phase is the under-budgeted one: most change programs spend their resources on the change phase, when the change phase is rarely the binding constraint. Most failed enterprise transitions failed in the unfreezing they never did.

Field theory's deeper claim — that behaviour is determined by the total field of forces in which the person finds themselves, not by character traits, dispositional preferences, or "skill levels" abstracted from context — is the same epistemological move that this paper has been making throughout. It moves the explanatory burden from the worker's interior to the worker's environment, and is the basis on which the rest of the change-management literature has been built. The action-research methodology Lewin introduced alongside field theory — iterative diagnose-act-reflect cycles, with participants as co-investigators — is the methodological commitment that follows from it, and remains the dominant model for serious change practice.

The post-Lewin formula most often cited in enterprise change practice is Gleicher's formula (David Gleicher, 1960s; popularised by Beckhard and Harris, then refined by Dannemiller into the form most commonly quoted): D × V × F > R. Dissatisfaction with the status quo, multiplied by Vision of the alternative, multiplied by the existence of concrete First steps, must exceed the Resistance to change. The multiplicative shape is the load-bearing part. Two ingredients at high values cannot compensate for a third at zero. A vision that is twice as inspiring cannot rescue a transition with no concrete first step; first steps that are twice as concrete cannot rescue a population with no felt dissatisfaction in the current state.

The Gleicher formula is what most "AI strategy" memos at large enterprises violate on inspection. They contain a V (a vision of a more productive workforce) and an F is implied (someone will set up the new tool). But D is typically absent — workers are not dissatisfied with their current practice, they are productive with it — and the multiplication therefore yields a product close to zero, against an indeterminate but real R. The change program does not begin. Telling workers they should be dissatisfied does not generate dissatisfaction; if anything, it raises R by adding insult to inertia.

The third frame is BJ Fogg's behaviour equation: B = MAP (Behaviour = Motivation × Ability × Prompt). Developed at Stanford's Persuasive Technology Lab in the 2000s and detailed in Tiny Habits (2019), it is the individual-habit analogue of the population-level formulas above. A behaviour happens when motivation, ability, and a prompt all coincide at the same moment. Fogg's contribution beyond earlier behaviourist traditions — Skinner's operant conditioning especially — is in the deliberate engineering of the Ability and Prompt terms: when motivation is unreliable (as it is for almost any change a worker has not chosen), the design lever is to make the behaviour so easy and so well-prompted that low motivation suffices. The corollary, which we return to in Pillar 7, is that architectural design can substitute for motivation up to a point — which is exactly the substrate-as-policy-enforcement move Bricks makes.

The relevance to the prevailing industry narrative is direct. "You are now using the new assistant" is a Prompt without an Ability investment (no training time was budgeted) and without a Motivation lever (no personal payoff was offered). The behaviour the management memo describes does not occur. The behaviour that actually occurs — visible irritation, slower output, transfer of cognitive load to evenings and weekends, eventual attrition — is exactly what the equation predicts.

The names in this section matter because they are the vocabulary by which the conversation about tool transitions is not a conversation about character. It is a conversation about which input the organisation forgot to supply, which restraining force it forgot to remove, and which threshold the multiplicative product failed to cross.

Pillar 4 — The asymmetry of downgrades: loss aversion, endowment, and autonomy

The strongest point in the reaction to this narrative — and the one that does the most analytical work — concerns the asymmetry of upgrades versus downgrades. Moving from a shovel to an excavator is also a tool transition, with its own retraining cost, but it is one the worker is broadly willing to absorb because the tool itself is doing some of the work of pulling them forward. Moving from an excavator to a shovel demands a higher payoff and more resources to achieve the same compliance, because there is no upward pull from the tool — the tool is now part of the resistance.

The behavioural literature accounts for this asymmetry through three related and well-replicated effects: loss aversion, the endowment effect, and status-quo bias. The names are different; the underlying empirical regularity is the same.

Loss aversion comes from Daniel Kahneman and Amos Tversky's Prospect Theory (1979) and was sharpened in their cumulative prospect theory work (1992). The finding, replicated across hundreds of studies and several decades of cross-cultural validation: losses are weighted approximately twice as heavily as equivalent gains in human decision-making. Losing €100 hurts roughly twice as much as gaining €100 pleases. The asymmetry is not a rounding error in the utility function; it is a structural feature of how humans evaluate change. The Nobel Prize that followed (Kahneman, 2002) attests to the durability of the finding.

The endowment effect — first formalised in Richard Thaler's 1980 paper and extensively documented by Kahneman, Knetsch, and Thaler — is the consequence of loss aversion for owned objects, capabilities, or practices. People assign more value to things they currently possess than to identical things they do not. A practitioner who has built their daily flow around a particular tool owns a practice in this strong sense — the tool is part of an integrated work surface they have invested in, customised, and adapted to. Removing the tool removes a part of the practice, not just a part of the toolkit. The compensation required to neutralise the loss is empirically about twice the compensation that would have produced the corresponding gain.

Status-quo bias (Samuelson and Zeckhauser, 1988) generalises the same finding to choice-architecture questions: people exhibit a strong preference for the default outcome, even when the default is no better than the alternative on the explicit criteria of choice. Inertia is not laziness; it is a measurable cognitive bias that compounds with loss aversion and the endowment effect to make any forced downgrade roughly three categories of resistance deep — the worker is simultaneously losing capability (loss aversion), unmaking a practice they owned (endowment), and leaving a familiar equilibrium (status quo).

The same mechanism — defending a default without having checked whether the alternative scored better on the explicit criteria — illuminates two particularly hard status quos inside developer culture. The first is the position that data protection is a cybersecurity question, a brake on innovation, or simply "not important"; a reading that collapses the moment GDPR is treated as an architectural discipline rather than a checkbox obligation (the posture developed in Security, Governance, and Data-Protection Framework Compatibility, and extended to accessibility and ecological footprint in Inclusion and Ecology, as Architecture). The second is the position that algorithmic sovereignty reduces to open source, a reading that misses the other three layers of sovereignty Bricks tries to restore — delegated, jurisdictional, and operational — layers developed in Toward a Digital Commons, Bricks' Theory of Change, and the participation pillar of Algorithmic Sovereignty by Deliberation. In both cases, what the industry conversation reads as common sense is in fact a default held in place by the joint pull of status-quo bias and cognitive endowment on an inherited framing.

The fourth and least-cited frame in the AI-adoption discourse is Self-Determination Theory (Edward Deci and Richard Ryan, 1985, with continuing programmatic work into the 2010s). SDT identifies three innate psychological needs whose satisfaction supports intrinsic motivation: autonomy (the sense of acting volitionally rather than being controlled), competence (the sense of being effective at what one does), and relatedness (the sense of being connected to others). Forced tool transitions reliably violate all three: autonomy is reduced (the change was not chosen), competence is temporarily destroyed (the worker is briefly worse at their job again), and relatedness is destabilised (the social fabric of "how we do things here" is disrupted). SDT predicts, and the empirical literature confirms, that compliance under such conditions is shallow and reverts as soon as monitoring relaxes. The behaviour visible in the resistance is not stubbornness; it is the predictable consequence of an intervention that simultaneously violated three of the four conditions of intrinsic motivation.

The implication for the AI-tooling conversation, when all four frames are stacked:

• A team moving from a less-capable IDE to a more-capable AI-augmented one is doing an upgrade against status-quo bias only. The tool itself supplies the driving force, and the worker often self-funds the retraining cost on evenings — autonomy is high (they chose the tool or feel they did), competence is rising (the new tool makes them better), and the endowment effect has not yet attached.
• A team moving from a frontier AI assistant to a less-capable replacement — for cost, contractual, or vendor-management reasons — is doing a downgrade that triggers all four effects simultaneously: loss aversion on the capability gap, endowment effect on the practice they had built around the previous tool, status-quo bias on the equilibrium they have to leave, and SDT-autonomy frustration on the fact that the choice was made for them. The compensatory investment required to keep their output level stable is empirically not double the upgrade investment; it is multiple times the upgrade investment, because the four resistances stack.
• The developer at the centre of the prevailing narrative is describing the second case. The commentary is reading them as if they were describing the first. The mismatch in framing is what makes the discourse read like contempt and the developer's complaint read like dependence.

The behavioural-psychology literature does not call this dependence. It calls it the predictable cost of an unequal trade, paid by the worker, in a regime where the employer has not budgeted for the trade's structural asymmetries. It is a budget failure compounded by a frame failure, not a character failure.

Pillar 5 — Behaviour as a process and a population: Prochaska and Rogers

The fifth frame is Prochaska and DiClemente's Transtheoretical Model (TTM), the dominant stages-of-change model in the behavioural-health literature since the 1980s. The five stages — pre-contemplation → contemplation → preparation → action → maintenance, with relapse a normal part of the cycle rather than a failure — were developed empirically from longitudinal studies of smoking cessation, then validated across addiction, medication adherence, exercise adoption, and several decades of clinical practice. Since the 1990s the model has been widely applied to workplace behaviour change, including tool adoption.

The TTM's first contribution is the most important one for our purposes: it names a fact that most enterprise change programs structurally ignore. Most workers are not in the "action" stage on the day the tool change is announced. They are distributed across the earlier stages — most heavily in pre-contemplation (unaware that change is coming, or aware and uninterested), contemplation (weighing the change), or preparation (gathering the resources to start). A change program that addresses only the workers already in "action" — the early adopters, the AI enthusiasts, the ones writing thought-leadership posts about how easy it all is — and treats everyone else as a laggard mistakes a population distribution for a moral hierarchy.

The TTM's second contribution is the body of empirical evidence — Prochaska's own meta-analyses and a substantial follow-on literature — showing that stage-matched interventions outperform stage-agnostic ones by large margins. A change program that uses the same communication, the same training, the same incentive structure for every worker regardless of stage delivers worse outcomes than one that distinguishes the supports required at each stage:

• Pre-contemplation workers need consciousness-raising information about why the change is coming and what it would mean for them personally — not training, which they cannot use, and not exhortation, which they will reject.
• Contemplation workers need clear scenario comparisons — status quo cost vs. transition cost vs. post-transition cost — and decisional-balance work to surface the trade-offs they are weighing internally.
• Preparation workers need access to tools, sandboxes, low-stakes practice, and committed time — what the literature calls self-liberation, the small first commitments that make the larger one feel achievable.
• Action workers need permission for a productivity dip, social reinforcement, and the absence of conflicting initiatives. They are doing the actual change work; piling additional change demands onto them at this stage is the modal way change programs collapse.
• Maintenance workers need recognition and stability. New disruptions to a maintenance-stage population trigger relapse — not as a failure of will but as a predictable consequence of overlapping change demands.

A management memo addressed to "everyone" satisfies none of these populations. A budget that funds only training (action-stage support) satisfies only the population that was already there.

The complementary population-level frame is Everett Rogers' Diffusion of Innovations (1962, with five editions of refinement through 2003). Where Prochaska describes the stages an individual passes through, Rogers describes the structure of an adopting population: innovators (2.5%), early adopters (13.5%), early majority (34%), late majority (34%), laggards (~16%), with adoption rates governed by perceived attributes of the innovation (relative advantage, compatibility, complexity, trialability, observability) and by the social-network structure through which information flows. The model has been validated across agricultural innovations, medical practice change, technology adoption, and organisational tool transitions, and is one of the most widely-cited frameworks in the social sciences.

The relevance to AI adoption is that the loudest voices in the discourse — the thought-leadership poster, the AI enthusiast, the early-adoption blogger — are by definition drawn from the innovator and early-adopter populations, who together represent about one-sixth of any normal adopting population. Reading their experience as representative of "what AI adoption is like" is a category mistake: it is what AI adoption is like for the population most predisposed to adopt anything. The early majority — the substantively important population whose adoption determines whether the innovation reaches scale — has different needs (compatibility with existing practice, observability of successful peer use, manageable complexity), and a change program optimised for the innovator population will systematically fail to meet them. The developer at the centre of the prevailing narrative is, in Rogers' vocabulary, very plausibly an early-majority adopter being asked to behave like an innovator with no support for the gap. The contempt directed at them is the contempt of the innovator population for the majority population, projected as a discourse about character.

Together, the frames named so far — Knoster's ingredients, Lewin's force field and unfreeze-change-refreeze, Gleicher's multiplicative threshold, Fogg's behaviour equation, the loss-aversion / endowment / status-quo / SDT stack, Prochaska's stage-matched supports, and Rogers' adoption-population structure — form what an organisation interested in actually changing what its workers do at work needs to commission, budget for, and measure. They are not novel; they are not obscure; they are not optional. The fact that the dominant register of the AI-adoption discourse in 2025–26 is moral rather than behavioural is itself a sign that the discourse is being run by people who have not done a serious tool transition before, or who are imitating the register of those who have not.

Pillar 6 — Bricks' architectural answer: AI as interface, not runtime

The behavioural framing above tells us what is psychologically true about tool transitions. The architectural framing tells us what Bricks has chosen to be structurally true about its own tool. The two are coupled.

Most products marketed as "AI-augmented" in 2025–26 wire an LLM into the runtime of the customer-facing application. The customer's request reaches a model on every call; the model's output is the application's behaviour; an outage at the model provider is an outage at the customer's product; a model deprecation is a re-engineering project; a pricing change is a margin event that the customer's business model has to absorb. Many of the most loudly-discussed "AI startups" of the period are this shape, and the migration-cost discussions in our companion Mature AI Operations whitepaper describe what that shape costs in practice.

Bricks is not this shape. AI in Bricks is the interface through which a human collaborator — the integrator, the small business owner, the freelancer — describes intent. The artefacts the AI produces are deterministic: a workflow row, an SDK call, a declared data flow, a signed CSP, an RLS policy, a database migration. Once produced, those artefacts run without an LLM in the path. A shipped Bricks application makes no Anthropic call to serve a customer. A workflow engine evaluates a typed expression DSL; a Postgres query returns a row; the SDK builds the page from declared concepts. The AI is the editor. The substrate is the runtime.

The consequence is the architectural counterpart to the psychological argument of the previous pillars:

• If Anthropic doubles its prices, every shipped Bricks app keeps running unchanged. Only the cost of building the next app changes.
• If Anthropic deprecates a model, every shipped Bricks app keeps running unchanged. Only the orchestrator's prompt-cache strategy has to be re-tuned.
• If Anthropic disappeared entirely overnight, every shipped Bricks app keeps running unchanged. Integrators continue to build new apps by writing workflows, declaring concepts, and editing the SDK directly through the Studio editor — slower, less ergonomic, but viable.

This is the property an "AI runtime" platform cannot offer. It is the property a deterministic-substrate-with-AI-as-interface platform offers by construction. The behavioural-psychology argument of this paper says that people will resist tool downgrades; the architectural argument says that Bricks has chosen an architecture where the downgrade scenario does not break what was already shipped, only what is being shipped next — and even there, it degrades the building experience rather than the running one.

The macroeconomic implication is the one Bricks stakes its growth model on: without AI, our growth is linear but assured; with AI, it is exponential. The linear path is the integrator path — a team of skilled humans using the platform's Studio editor and SDK directly, building applications at a rate bounded by the size of the team. The exponential path is the AI-mediated path — any small business, association, or freelancer describing intent in natural language to the orchestrator, building applications at a rate bounded by the marginal cost of an AI turn. The first is a sustainable business. The second is what allows the platform to reach the long tail that GAFAM-priced software has structurally excluded: the tens of thousands of communes, the millions of small associations, the freelancers and craft businesses and cultural infrastructure that custom-software pricing has never accommodated.

The choice to make AI an interface rather than a runtime is therefore not only a technical decision. It is the mechanism by which the platform's mission — to take software production capacity back from the GAFAM concentration and return it to the long tail — survives any plausible adverse event in the AI ecosystem. A platform that depends on AI at runtime is one regulatory shock away from collapsing back into the consolidation it claims to challenge. A platform whose AI is an interface is not.

Pillar 7 — When policy is not enough: the harness as the behavioural lever

The behavioural-psychology pillars above describe what an organisation must supply for a tool transition to succeed: ingredients (Knoster), capability and motivation (COM-B), driving forces over restraining forces (Lewin), a multiplicative threshold (Gleicher), motivation–ability–prompt (Fogg). Each frame names something the change program must commission, budget for, and deliver. Each presumes that the user is the actor whose behaviour the change program is trying to alter.

Bricks takes a complementary path the behavioural-psychology literature less frequently discusses but that operationalises the same constraints in the opposite direction. We accept the literature's finding that policy alone — a memo, a directive, a stated value — is not enough; we know what fails. Our principal response, however, is not to supply the ingredients required to make policy work on the user. It is to embed the policy into the tool itself, so that the policy executes whether the user has internalised it or not, and so the desired behaviour is the path of least resistance rather than the path of greatest effort.

This is the operational thesis of the platform's approach to GDPR, accessibility, ecological footprint, security headers, and role-based access control. It is the same approach we extend to the AI orchestrator. The principle has been documented elsewhere, in adjacent literatures, under names like architectural compliance, defaults-by-design, forcing functions, and — most precisely — Lawrence Lessig's Code is law claim, that the technical substrate of a system performs a regulatory function whether or not anyone has written the regulation down.

The behavioural-psychology frame that maps most cleanly onto it is Fogg's. In B = Motivation × Ability × Prompt, an architecture that maximises Ability (the tool makes the right thing trivial to do) and Prompt (the tool surfaces the right path by default) can succeed even when Motivation is low or absent. The behaviour change happens not because the worker has been convinced, trained, and incentivised into wanting it, but because the substrate has been engineered so that the desired behaviour is the easy one and the undesired behaviour is the hard one or the impossible one. Knoster's grid is satisfied not by supplying skills to every individual user but by displacing the requirement for skills into the harness, where one platform engineer's work substitutes for a training program every customer would otherwise have to commission independently.

The strategic claim that follows is large, and we want to state it plainly:

A platform that embeds its policy commitments into the tool surface delivers those commitments to every customer at near-zero per-customer cost — including, crucially, to customers who are not personally interested in the commitments. The customer's data-protection posture, accessibility posture, ecological footprint, security headers, and role-based access controls do not depend on the customer caring about any of them. They depend on the platform engineering team having shipped them once.

The empirical record on Bricks supports this directly. Our customer base includes small business owners, freelancers, and association volunteers who have never read the GDPR, have no opinion on the European Accessibility Act, do not know what an Ecoindex score is, and would not pay €500 of consulting for a DPA template if asked. They receive all of those properties as a side effect of being on the platform. The compliance posture they end up with is materially stronger than what most €20,000–€50,000 consulting engagements deliver, and the per-customer marginal cost to Bricks of supplying it is close to zero, because the work was done once by a platform engineer and propagates to every tenant on the next publish.

This is the socio-techno-economic model the platform is built around. Customers who are interested in the social and legal commitments encoded in the platform are welcomed and given the language to articulate why those commitments matter. Customers who are not interested receive the same commitments anyway, in a form they did not have to evaluate or buy. The platform's strategy and values are active through the tool, not aspirational through the policy. The user does not need to be convinced for the user's app to comply.

The same logic governs how Bricks approaches its own AI orchestrator. We invest comparatively little effort in heavy prompt engineering, in custom fine-tuning, in elaborate few-shot example libraries, in vendor-specific training-data investments, or in any of the artefacts a chat-AI-centred startup might consider its principal IP. The deterministic substrate — the workflow engine, the SDK, the typed expression DSL, the data-flow registry, the semantic graph store, the multi-breakpoint cache layout, the boilerplate refresh on every publish — does the work that a heavily-prompted model would otherwise have to do. The orchestrator's job is to route intent into the substrate; the substrate produces the artefacts. The behaviour Bricks delivers does not depend on the prompt being a long, careful, vendor-specific composition; it depends on the substrate being correctly engineered.

The consequence is a vendor-relationship posture markedly different from AI startups whose principal IP lives in their prompt:

• A model swap at the platform level costs us a re-tuning of the orchestrator's cache discipline and a small re-calibration of prose-length expectations. It does not strand the IP that drives our product, because that IP does not live in the prompt.
• A model deprecation costs us a similar re-calibration. Customers do not see it. Apps already shipped do not see it.
• A regulatory or geopolitical shock at the AI vendor level — a sudden export-control regime, a court-ordered shutdown, a pricing renegotiation, a fine-tuning capability disappearing — does not collapse our offer. The substrate keeps running; the integrators keep building; the AI-mediated building experience degrades gracefully into the direct-substrate building experience the integrators were already using.

This is the architectural expression of the same behavioural-psychology insight the earlier pillars described from the worker's side. The literature says that policy without ingredients fails. Bricks responds by removing the need for the user-side ingredients to be supplied, and absorbing them into the platform side, where one round of platform engineering supplies them for every tenant simultaneously. The result is a product whose social, legal, and ecological commitments are executed at the architectural level rather than the policy level — and a customer experience in which the customer does not have to be convinced of the commitments in order to benefit from them.

The connection to the strategic positioning of the The End of the Developer Role and The Macroeconomics of Bricks whitepapers is direct: this is what makes the AI-mediated long-tail path economically possible. A platform that required every small business owner to personally internalise GDPR, accessibility, AI prompt engineering, and security architecture before they could ship a working application is a platform that would never reach the long tail. A platform that embeds those commitments into the substrate and offers the AI as the natural-language interface to that substrate is the platform that does. The behavioural-psychology framing tells us why the policy-only path fails; the architectural choice tells us how the substrate-enforced path succeeds; the platform-engineering practice is what holds the two together.

Pillar 8 — What this implies for how Bricks onboards and supports

The behavioural-psychology frames are not academic decoration; they are the operational standard by which Bricks evaluates its own onboarding, migration, and partner-support work. The five ingredients of Knoster's grid, the three components of COM-B, the multiplicative shape of Gleicher's formula — these are the checklist against which we ask whether a given migration brief is actually going to succeed.

The concrete commitments that follow:

• Integrator onboarding budgets the productivity dip. A developer transitioning from a per-application practice into a platform-engineering or integration practice will be slower for the first three to six weeks. The partner program priced the dip explicitly into its support commitments rather than expecting partners to absorb it silently. This is the Knoster resources ingredient, named.
• Migration paths are gradual, never abrupt. When an integrator brings a customer onto Bricks who is leaving a custom-built application, the path is staged: catalogue the existing functionality, identify the platform primitives that cover it, migrate one capability at a time, leave the legacy system running in parallel until the new one is stable. This is the Lewin unfreeze → change → refreeze sequence applied to a multi-month customer relationship.
• Personal incentives for integrators are real. A partner who refers a customer earns a share of the wallet revenue for the lifetime of the customer's relationship. A platform engineer who ships a primitive that improves output across all tenants is recognised on the platform-events log that drives the cost dashboard. This is the Knoster incentives ingredient, the COM-B motivation component, and the Gleicher formula's vision term simultaneously addressed.
• Tooling-transition coaching is part of the integrator brief. When an integrator brings a small business onto Bricks who is leaving Excel, a SaaS subscription, or a manual paper process, the integrator's job is not only to ship the app — it is to support the people whose habits the app is going to change. The Prochaska stages-of-change model is the vocabulary we use internally for that part of the engagement, even if we do not impose the vocabulary on the customer.
• Downgrade scenarios are sized at twice the upgrade cost. When a customer or an integrator must adopt a less-capable variant of a tool — a stricter mode for compliance reasons, a smaller-model fallback when the wallet is low, a manual workflow when an automation is removed — the support budget assumes the loss-aversion asymmetry. The investment required to make the downgrade stable is roughly twice the investment that produced the upgrade. Pretending otherwise is a recipe for failed transitions and partner attrition.

The contrast with the modal AI-vendor onboarding posture of 2025–26 is sharp. Most AI vendors treat the population of workers affected by the tool change as a single undifferentiated group ready to be in the "action" stage on the day the contract is signed. Most do not separate dependence from habit, do not budget the productivity dip, and do not size the downgrade asymmetry. The resulting attrition — the developer at the centre of the prevailing narrative is one data point among many — is then read as a property of the workers rather than of the change program. The behavioural-psychology frames make the misreading impossible.

Pillar 9 — Why this matters beyond Bricks

The argument of this paper has two parts that read as separate but are not. The first is psychological: tool transitions in enterprise have an operational vocabulary, sixty years old, that the AI-adoption discourse has been declining to use. The second is architectural: Bricks has chosen an AI-as-interface posture that decouples its platform's runtime from the AI ecosystem's volatility, leaving only its building experience exposed.

The two parts join at the question the AI-adoption discourse is actually about: what kind of relationship are workers going to have with the AI tools that increasingly mediate their work?

A platform that wires AI into the customer's runtime is offering a relationship of runtime dependence — the customer's product cannot exist without an active AI provider, and any change to the AI provider is a change to the customer's product. A platform that wires AI into the editor is offering a relationship of interface mediation — the customer's product can exist without the AI, and the AI is the tool by which the customer's intent reaches the substrate that builds the product. The first is the GAFAM posture: a small number of large vendors holding the operational stack of every business that buys their products. The second is a different posture, one Bricks shares with the participatory-AI and inspectable-algorithms traditions described in our companion whitepapers.

The behavioural-psychology framing is what makes the difference politically legible. A worker who is told they "depend on" an AI tool is being told a story about themselves that the literature does not support. What is happening is that the AI provider has captured part of the worker's practice, and the employer has not budgeted the ingredients required to absorb a change to that capture. The framing of "dependence" makes the worker responsible for what is, structurally, a question about who controls the operational stack of their work — and that framing is in the interest of whoever controls the stack.

The opposite framing — "your habits are real, your transition costs are real, and the platform must supply the ingredients required for the change to succeed" — puts the responsibility back where the literature says it belongs: on the change program, on the budget, on the platform engineer, and on the architecture that decides whether the AI is interface or runtime. It is the framing Bricks commits to internally and the one we want to see become standard externally.

The growth model we have committed to follows directly. Without AI, we can serve our integrator and partner channel sustainably: linear, modest, but real. With AI, the same platform reaches every small business, association, commune, and freelancer that custom software has never been priced for: exponential, mission-critical, and the only path by which the long tail is brought back inside the digital economy on terms it can afford. The two halves are independently viable; together they are how Bricks completes its mission of returning software-production capacity to the long tail. Neither half depends on the developers in the prevailing narrative being shamed out of their habits. Both halves depend on the platform doing the change-management work the literature has been documenting for sixty years.

Pillar 10 — The human in the loop, the dev cell out of the silo

The two strategic pillars above describe how Bricks operationalises its policy commitments through the substrate rather than through user-side discipline, and how that choice connects to the platform's position in the AI ecosystem. The accumulating implication, when stated plainly, is that the platform is doing a form of constructive social engineering — not in the security-attack sense the term sometimes carries in 2020s discourse, but in the Lewinian sense that the word carried before security culture appropriated it, and in the sense in which urban planning, public-health communication, and choice-architecture work in the Thaler-Sunstein tradition are all explicitly social engineering. Bricks shapes the behaviour of the people in its loop — integrators, end users, customers, regulators, and indirectly the AI providers we transact with — through the architecture of the tools they touch, in the direction of outcomes the platform has committed to delivering.

We use the term openly because we think being explicit about it is part of the honest version of the relationship the platform has with the people it serves. A tool that quietly orients every customer's app toward GDPR compliance, accessibility, low ecological footprint, and inspectable audit trails is engineering social outcomes — and the only choice on the table is whether the engineering is acknowledged and debated or hidden and unaccountable. We prefer acknowledged and debated.

The operational consequence is the one that explains a structural feature of the Bricks team sometimes commented on by outside observers: the development cell pays unusually close attention to non-technical subjects — behavioural psychology, regulatory law, accessibility doctrine, ecological design, deliberative-democracy theory, organisational change management, the political economy of platform concentration. Each of these is the subject of a separate whitepaper in this collection, written by the same small team that writes the platform code. The collection is not the product of a marketing department, an external consulting brief, or an academic affiliation. It is the product of the engineering team taking these literatures seriously enough to read them and to encode their commitments into the substrate.

The reason is not that the team is composed of hobbyist generalists who happen to enjoy reading widely. The reason is structural: a platform that embeds its policy commitments into the substrate cannot delegate the design of those commitments to the substrate. Someone has to know what the GDPR actually requires before the data-flow registry can encode it. Someone has to know what the European Accessibility Act mandates before the platform's a11y defaults can satisfy it. Someone has to know what the behavioural-psychology literature says about tool transitions before the integrator onboarding budget can be sized correctly. Someone has to know how Arnstein's participation ladder works before the workflow engine can be designed as an inspectable artefact in the democratic-deliberation sense. The non-technical literatures are not adjacent to the platform's engineering work; they are the upstream specifications of what the engineering must enforce, and the team is the only place in the organisation where the specification and the implementation can be reconciled in a coherent way.

The corollary, equally structural, is that the platform's success — as a platform, as a business, and as a participant in a society in continuous evolution — depends on the dev cell keeping its interdisciplinary surface alive over time. A team that closes itself into pure code work cannot continue to encode the regulatory, social, and ecological commitments that justify the substrate's existence; the commitments stop being updated and the platform drifts out of alignment with the literatures it was meant to enforce. A team that stays open to the literatures continues to ship a platform whose social engineering is in the direction the team has examined and committed to, rather than drifted into by the path of least implementation effort.

The human in the loop — the integrator, the small business owner, the end-user customer, the regulator reading our compliance frameworks, the journalist writing about our positioning, the AI provider whose model we route intent through — is therefore an active component of the platform's economic and algorithmic model, not a recipient of either. The substrate enforces behaviour; the team specifies what the substrate enforces; the literatures specify what the team should be specifying for. The chain has to remain unbroken for the platform's commitments to remain coherent over time, and the dev cell's continuous engagement with non-technical subjects is what keeps it unbroken.

This is the third claim we want to make explicit in this paper, alongside the psychological and architectural claims above:

Bricks is, by construction, a social-engineering platform. The behavioural-psychology literature names the dynamics of human tool use; the architectural choice to make AI an interface rather than a runtime positions the substrate to absorb the dynamics on the platform side rather than offload them onto the user; and the dev cell's interdisciplinary practice is what keeps the substrate's specification aligned with the dynamics over time. None of the three is optional. None of the three can be outsourced.

It is also the claim that explains why a small engineering team in Belgium writes a collection of whitepapers on regulatory law, behavioural psychology, accessibility, ecological design, financial architecture, and democratic governance. The work the team is doing is the work of specifying what a platform that takes those literatures seriously needs to enforce. The collection is the specification, written out. The platform is the specification, executed.

Conclusion

The industry narrative that prompted this paper is one expression of a much broader pattern. The register it deploys — moral, contemptuous, individual-focused — is the dominant register of the current AI-adoption discourse. The behavioural-psychology literature has had a different and more accurate vocabulary available the whole time, and the operational consequences of using that vocabulary are concrete and measurable.

We have named the frames — Knoster, Lewin, Gleicher, Fogg, Prochaska, Rogers, Kahneman and Tversky, Deci and Ryan, with COM-B as the higher-altitude clinical-tradition summary readers can use as an entry point — because we want them in circulation, and because we expect anyone making a real change decision to read past our gloss into the literatures themselves. We have anchored Bricks' architectural choice — AI as interface, not as runtime — to the same frames, because the two are coupled: an organisation that takes the behavioural framing seriously also takes the architectural framing seriously, and vice versa. We have closed by stating openly that the platform is a social-engineering project, that the dev cell's interdisciplinary practice is what keeps the project honest, and that none of the three claims can be outsourced without breaking the chain. We are not the first platform to make any of these choices, but we are explicit about making all three, and we believe the explicitness is itself part of the mission.

The closing observation is the one we want to leave with leaders, regulators, and partners thinking about AI adoption:

You do not have an AI-adoption problem. You have a habit-change problem with an AI catalyst. The literature on habit change is sixty years old, it has names, it has formulas, and it will tell you what to budget for. The literature on AI adoption is two years old, it does not have those names, and it has been used so far to shame the workers whose habits the management memo did not budget for changing. Switch literatures. The transition will go faster.

Bricks is built by a small team in Belgium. Our growth without AI is linear but assured; our growth with AI is what brings the long tail back into the digital economy. If you would like to discuss this paper, or the change-management implications of a tool migration in your own organisation, write to us at hello@bricks-softwares.com — we would rather hear from you than guess.