AI as a Qualitative Turning Point: When Compute Power Forces Reorganization of Knowledge Work
This article analyzes why AI represents a qualitative shift in the compute revolution by examining historical parallels with steam and electricity revolutions, arguing that AI's entry into analysis and judgment tasks creates pressure to restructure organizational authority, responsibility, and coordination — not just improve individual productivity.
The article opens with a management scenario: a customer requests early delivery, sales wants to keep the order, production fears schedule disruption, procurement finds substitute materials, but quality cannot approve. Each department acts responsibly, yet the enterprise cannot give a commit-able answer. Adding AI speeds up individual tasks — sales organizes client data faster, procurement compares suppliers quicker, production calculates schedules faster — but if authority over substitute approval, other customers' schedule adjustments, and cost acceptance remains unclear, better proposals still stall in coordination meetings.
The core question: when AI changes capabilities for information gathering, analysis, and partial execution, do existing division-of-labor and authority structures still fit the same business outcome? To answer, the author places AI in the lineage of three productivity revolutions: power (steam), energy (electricity), and compute (computers, networks, AI). The General Purpose Technology framework (Bresnahan & Trajtenberg, 1995) helps explain: a technology used across many domains, with inherent improvement potential, and complementarities with application innovations. Its impact extends beyond device efficiency to the products, processes, skills, and organizations that form around it.
Two types of change are distinguished: "switching source" (换源) — changing the capability source for existing work (e.g., electric motor driving old line shaft, software processing old forms, giving employees AI assistants) — and "reconstruction" (再造) — changing how capabilities are organized to do work (adjusting equipment layout, process handoffs, task division, decision rights). The distinction identifies where change occurs, not a mandatory sequence.
Power Revolution: Machine Production and Factory System Co-evolved
Arkwright's 1771 water-powered spinning mill at Cromford concentrated machinery, workers, and management, requiring common working hours, process coordination, and on-site supervision. Labor began to be organized around centralized machinery — individual work increasingly constrained by the collective production process. This factory organization developed under water power, before mature rotary steam power. The British Science Museum's 1788 rotary steam engine, used in Birmingham to drive multiple metal-polishing machines, shows steam expanding from pumping into machine production. As performance and economics improved, steam reduced dependence on suitable water sites and extended production-market reach via transport. Yet fuel, water, transport, and equipment costs still constrained siting; factories did not escape all geography.
New power could drive more machines but would not arrange all processes for managers. Raw material entry, worker coordination, handoff timing, authority over work rhythm — still required organizational solutions. Centralized power enlarged scale of joint production, making hiring, command, supervision, and specialized division of labor more prominent relations. Crafts (2004) growth accounting shows steam's contribution to British growth accumulated over long periods; water power remained competitive in many conditions. Continued water use cannot be dismissed as resistance to progress. Only when new power fits actual use, cost, and organizational capability does reconstruction have business justification.
Energy Revolution: Flexible Power Delivery Enabled New Layouts
In factories reliant on central mechanical transmission, a prime mover drove multiple machines via line shafts and belts. Workers carried work-in-process between equipment; machine placement and adjustment were limited by transmission structure. Production needed smooth process flow, but power had to follow existing shafts — the two often conflicted. Electricity provided new spatial freedom. Factories could use electric motors to drive old shafts (group drive), break transmission into smaller machine groups, or give individual machines independent power (unit drive). Devine (1983) distinguished these arrangements; group drive already brought flexibility and organizational improvement, unit drive further reduced dependence on common shafts. Different modes coexisted long-term; choice depended on process, equipment, and cost.
When machines could draw power independently, managers could arrange equipment by processing sequence and material flow, reducing handling needed to accommodate transmission structure. Workshops no longer had to organize around power sources; they could design around how products get completed. Resulting gains came not only from power use itself but from layout, handoff, and labor organization changes. Ford's 1913 Highland Park moving assembly line combined interchangeable parts, fine division of labor, and continuous material flow — a landmark production-mode change — but cannot be attributed solely to electric motors, nor treated as a universal transformation year for all industries.
In this production mode, gains and human conditions were tightly linked. Equipment placement determined how people coordinated; rhythm setting affected labor intensity and autonomy; after output rose, how gains were distributed among investors, managers, and workers became new management and social issues. Electrification's significance thus exceeded machine upgrades, entering command, coordination, and interest relations. David (1990) reminded that old plants and equipment retained use value; rebuilding costs money; firms won't simultaneously shut down and rebuild just because a new technology appears. New plants can exploit new conditions from design; old plants must compare continued use vs. retrofit cost. Technology being available and retrofit being economical are different judgments. This explains why organizational change often lags tool adoption: old arrangements carry live orders, familiar skills, and sustaining investments. Reconfiguring requires design, trial, and learning; waiting sometimes reflects rational trade-offs, sometimes habits and power that have lost justification.
Compute Revolution: From Information Processing to Participating in Analysis, Judgment, Execution
Compute revolution first vastly expanded information-processing scale and speed. Computers, software, and networks connected previously scattered business records, enabling more transactions, longer supply-chain coordination, and larger-scale work organization. Technology and organization mutually shaped each other: mainframes expanded centralized business processing; PCs let more roles use computing tools directly; networks and cloud changed how information connects and compute resources are accessed. These forms keep overlaying, not retiring in neat succession.
Hammer's 1990 Business Process Reengineering emphasized designing work around outcomes. Bresnahan, Brynjolfsson, and Hitt (2002) discussed IT complementarities with broader job responsibilities, decentralized decision-making, and team organization. Process, role, and decision-relation changes have long been part of the compute revolution. Kroszner (2006) gave retail examples: IT combined with retail practices to improve supplier-retailer supply-chain coordination, making order progress more visible. For a chain enterprise, even if store information transmits faster, if replenishment rules, supply collaboration, and personnel actions don't change, information value may stop at reports — an inference equally applicable to today's AI observation.
AI is not the first to give organizations conditions to reduce layers, redesign processes, or expand collaboration. Its advance lies in the types of work machines can participate in. For many well-bounded businesses, software follows pre-designed rules; facing new customer requirements, incomplete materials, or conflicting conditions, understanding, analysis, and coordination have long depended heavily on people. AI is expanding the task range machines can assist with, enabling machine help for work difficult to pre-specify as rules.
Example: an early-delivery request. Legacy systems can query inventory, orders, and schedules; linking these records, interpreting what the customer really needs, comparing adjustment costs — typically done by people across roles. With appropriate models and tools, parts of material synthesis, option comparison, and even execution steps can be completed by AI under conditions where humans set goals, grant permissions, and verify results. Enterprises can thus use AI-provided analysis, option suggestions, and task-execution support in concrete business.
This change goes beyond doing the same calculation faster. Previously, which role received a work segment often determined where needed knowledge was obtained; now, some capabilities previously requiring expert presence can — after expression, authorization, and verification — serve more tasks. People still provide professional judgment, but the mapping between work and roles gains recombination space. Id and Talamas (2025) "AI in the Knowledge Economy" starts from AI taking on parts of mental work hard to pre-specify as explicit rules, discussing how knowledge division of labor and human returns may change. The model indicates AI entering as assistant vs. autonomous executor leads to different organizational and distributional consequences; cannot pre-assign all enterprises to one future form.
Why AI Is a Qualitative Moment: Capability Supply Touches Division of Labor and Authority
Knowledge work has a new capability source; are existing coordination methods still fit? This question brings AI's change in the compute revolution to division of labor and authority relations. Returning to the delivery request: waiting used to occur mainly in gathering materials, requesting expert analysis, forming alternative proposals. If AI markedly accelerates these, but a well-conditioned decision still requires multi-layer coordination and step-by-step escalation, adding more model capacity won't eliminate the remaining wait. Arrangements originally formed to concentrate knowledge and coordinate specialized division of labor need re-examination: which still guard necessary boundaries, which now block actionable work?
When such waiting affects customer response, increases coordination cost, or makes the enterprise miss capturable business opportunities, adjustment gains real pressure. "Forced" (倒逼) happens here: new capability opens new production possibilities, but existing division of labor and authority limit realization of those possibilities; managers must handle the mismatch. Pressure comes from concrete business situations, not declarable by a tech demo alone.
How organizations originally concentrated knowledge is also affected. Experts passing experience to a few familiar colleagues vs. making verified partial experience callable by more tasks create different capability-supply ranges. If all users must still wait for the original expert each time, every person's AI-added proposals may congest at a few judgment nodes; if all judgment is pushed out, professional quality may be lost. Enterprises must re-distinguish reusable knowledge, professional judgments that must remain personal, and decision rights that can move forward under explicit conditions.
Coordination-cost change is two-sided. AI helps people understand cross-department materials faster, but also generates more alternative proposals, verification work, and exceptions. It may support frontline autonomy or strengthen headquarters' centralized analysis capacity. Final division depends on whether knowledge can be reliably used, error consequences, and responsibility arrangements — cannot be derived from tool distribution alone.
Capabilities can be recombined; decision rights and responsibilities cannot be ambiguous. Model proposes schedule change ≠ authority to affect another customer; identifies risk ≠ authority to accept risk for the enterprise. Enterprises must simultaneously answer: which work can human-AI combinations complete, which decisions can move forward, which professional judgments must be independently retained, who bears responsibility for the whole outcome, and how incremental gains are shared.
"Production relations reconstruction" at the enterprise-organization level means adjusting division of labor, command/coordination, capability use, and benefit distribution. It involves who controls and invokes key capabilities, who holds decision rights, who bears responsibility, who shares gains, and affects how employees grow and voice dissent. The article discusses enterprise-level relation changes, not asserting inevitable ownership changes.
Electricity analogy has limits: AI analysis can err; experts still bear training, judgment, professional responsibility; knowledge cannot be treated like current — plug into an interface and use reliably. This difference determines that the AI era requires simultaneously re-examining capability configuration and responsibility arrangement.
Era turning point and enterprise realization operate at two levels: the former is available production methods changing; the latter is the enterprise actually changing who decides in which situations, how actions are coordinated, who bears consequences and shares gains. Whether such change is necessary or worthwhile must be tested in concrete business.
From One Delivery Request: Connecting Capability, Power, Responsibility
Macro change lands in enterprises as how a single decision gets made. For the opening delivery request, enterprise should first separate assessment from commitment: forming a feasible plan ≠ promising early delivery. Sales states customer need and commercial value; production gives scheduling constraints; procurement offers supply options; quality completes necessary verification; AI assists fact organization and option comparison — all serving one clear result: can the enterprise accept this request, and at what cost?
Continuing the scenario: previously, order owners struggled to timely see adjustment impacts on other orders and costs, relying on centralized analysis and GM coordination. Now, within authorized scope, AI links business records, organizes conflicts, compares options; key evidence verified by relevant professionals; order owners more easily obtain complete judgment materials. If such analysis reaches required reliability in actual use, enterprise gains conditions to move decision rights forward for common cases.
Concrete authorization: within preset cost limits, no impact on other customer commitments, and passing professional verification → authorized order owner decides which internal option to adopt; commercial owner with external-commitment authority completes customer negotiation; after agreement, organize fulfillment. Cost-limit breaches or cross-customer trade-offs go to those authorized for that conflict. This changes decision rights and coordination for common cases.
In this scenario, order owner bears responsibility for integrating parties, organizing trade-offs, explaining complete result; professionals retain respective judgment responsibilities. Quality verification not passed → schedule pressure cannot substitute professional conclusion; AI evidence unreliable → recheck or use other methods. Assigning whole result to one person ≠ loading all professional responsibilities onto them; internal responsibility division cannot become excuse to evade external responsibility.
For this arrangement to work, participants must jointly know: what the result is, where boundaries lie, what judgments each can make, by what to accept, when to stop or escalate. Information, resources, permissions must arrive with responsibility; otherwise the "result owner" becomes a new pressure absorber. Tasks can combine dynamically; responsibility must always have someone to carry it.
Starting from concrete business scenarios, first clarify for whom to produce what result, then arrange capabilities, tasks, responsibilities — only then can enterprise judge which relations are worth changing. Payroll, standard procurement, and other well-bounded work already have reliable processes — continue using them. Even for delivery requests, if implementing existing authorization or fixing an interface suffices, no need to expand reconstruction.
Front End Needs Reliable Core Capabilities to Act
One delivery assessment succeeding is only local progress. If each department builds its own agents, procurement, production, sales may store different supplier-qualification judgments; when a rule changes, some systems update, others still use old versions. More local capabilities → more time explaining differences, verifying bases, re-coordinating.
Need a common organizational arrangement so front-end action has reliable support. Mycelium organization's "strong core, agile front" answers this: strong core guards mission, shared facts, professional standards, identity/permissions, public capabilities, risk bottom lines; agile front nears customers and field, senses, combines, acts within boundaries. Core provides trustworthy support; front end can then autonomously judge within appropriate range.
Shared capability value shows in whether business acts more reliably; if core turns all use into new approval rounds, it becomes a new waiting center. Power-grid analogy still useful: shared capabilities reusable, front end needn't each build full foundation; but enterprise-provided public capabilities must carry explanation and responsibility — letting users know applicable problems, factual basis, maintenance owner, result verification. Only model interfaces without these shared conventions leave work stuck in mutual waiting and repeated confirmation. Cloud platforms provide compute and model services; enterprise public capabilities must connect own facts, professional standards, authorization relations into work — different responsibilities.
Organizational arrangement entering daily operation needs corresponding digital support. One delivery assessment crosses sales, procurement, production, quality systems; each keeps own business records, but work must advance as a whole continuously. Participants need to know: who currently responsible, which conditions satisfied, what decision can be made next, who takes over on exception. Thus AI-era enterprises need a digital carrier that carries cross-system work order, organizing scattered capabilities and actions across systems.
This carrier can form gradually by transforming and connecting existing systems. Order, inventory, quality facts still maintained by respective systems; digital carrier connects cross-system tasks, permissions, evidence, exception handling — making collaboration executable and traceable. System-building starting point: let valuable work complete continuously, then precipitate repeatedly needed capabilities into shared support. Fact sources, necessary permissions, responsibility boundaries clarified before front-end action; remaining capabilities can improve with real scenarios; building complete platform should not be prerequisite for solving first problem.
Public capabilities must grow from real work. One delivery assessment ends: besides accepting customer result, enterprise should retain which judgments held, which facts insufficient, why a proposal was rejected. E.g., certain substitute materials repeatedly blocked for lack of verification data → organize required data and applicable conditions into candidate specification. Let qualified people outside original team use in similar situations, pass independent acceptance, authorized adoption → experience enters shared rules with basis; after adoption, still need maintenance, correction or retirement when conditions change. This is "solve one problem, standardize a class of problems": enterprise identifies reusable parts from one success, subjects them to verification beyond original team.
Organizational capability growth = whether effective experience works beyond original team. Digital carrier bears work; organizational learning improves shared capabilities; together they let front end avoid re-finding answers and re-coordinating relations each time.
Enterprise Cannot Shut Down to Restart: Business Model, Culture, People Must Move Together
Old plant still has orders to deliver; old organization has customers, employees, cash flow to maintain. Managers face not paper comparison of new vs. old, but how to maintain operations while creating space for next work mode. New business/teams less constrained by existing structure — suitable for designing clear authority-capability relations from start; existing business can use system-update, capacity-adjustment, process-improvement windows to test in segments. Differences don't inherently prove new organization more advanced — must compare business difficulty, people capability, resource investment.
Resource-constrained enterprises can start from one or two adjacent business situations, reuse existing systems and people. Small pilot ≠ responsibility arrangement can be vague; small scale ≠ must copy large enterprise's full platform. First let one genuinely valuable problem get repeatable solution, then judge extension — usually more meaningful than launching many disconnected demos simultaneously.
Business model determines how reconstruction gets funded. If billing by service hours, efficiency gains may reduce revenue. If customers value responsiveness and reliability, can new capabilities support different service promises and pricing? If saved time only completes same service earlier, no new customers, freed capacity not converted to cost savings → profit may not rise. This doesn't erase value of less overtime or better service, but requires operators to explain how new capabilities get sustained funding. Cost savings can be valid gain; new revenue can be direction; not necessary to demand every AI improvement simultaneously complete business-model revolution.
Culture affects willingness to bring real problems into new systems, visible in concrete trade-offs: department gives up local convenience for customer joint outcome → recognized or penalized in own department KPI? Employee flags model error → manager pauses to verify or demands compliance? These repeated choices determine actual work more than "embrace AI" slogans. Asking a senior expert to hand over years of accumulated methods — if enterprise only calculates headcount saved — they reasonably fear helping organization weaken their position. Mere encouragement of "embrace change" cannot eliminate this interest conflict.
If professional experience gets reused by more teams, contributor's evaluation and reward should consider contribution to joint results, not just personal cases handled. Those bearing maintenance, training, correction also need corresponding time and resources. Enterprise arranging growth opportunities, recognition, gains, while preparing training and transition for role changes — only then does knowledge sharing have sustained interest basis.
Roles still carry professional accumulation, people development, long-term responsibility; task fluidity ≠ breaking people into replaceable parts. Middle management not reduced to only approval or elimination: defining problems, training people, maintaining standards, handling exceptions — originally important management work.
Supervision must also change. If every exposed exception immediately becomes accountability chase, employees may hide problems, system feedback distorts. Should distinguish honest reporting, reasonable trial-and-error, negligence; preserve professional dissent, appeal, stop-action channels; clarify how operation records are used. Responsibility configured together with information, permissions, resources, rewards — reconstruction not just passing pressure down differently.
Leaders therefore bear both business and relation-adjustment responsibility: resource for exploration, verifiable stage goals; clarify which capabilities to develop; honestly communicate role-change costs. Tech teams can help build tools; how contributions recognized, interests adjusted, transition borne — needs enterprise to actually decide. These arrangements affect transformation cost and speed, determine whether new work mode sustains. They are not "soft work" added after tech project completes, but business choices needed simultaneously when production relations change.
Whether Reconstruction Is Worth It — Answered by Business Results
Technology opens new production possibilities; business results decide whether new organizational arrangements are worth sustaining. For enterprises, must see both whether work relations truly changed and whether such change sustainably delivers reliable results.
Work mode already adjusted, but labor income and recorded hours may not yet show significant change. Humlum & Westhøj (2026, revised) linked AI adoption survey with Danish administrative labor records, observed AI-related new tasks and work adjustments; but up to Dec 2024 (~2 years post-ChatGPT), no significant impact on labor income or recorded hours detected. This reminds: cannot use temporarily static labor indicators to reverse-prove work relations unchanged; nor see relations change and prematurely declare economic returns realized.
Alternative explanation: complementary investments not yet yielding returns. Brynjolfsson, Rock, Syverson's productivity J-curve incorporates intangible investments — processes, skills, management experience: firms invest first, some results appear later, statistics may not timely reflect. This requires enterprises to identify what capabilities are forming, how investments turn into observable results — cannot assume every temporarily loss-making project worth waiting for.
Model capability and supervision cost remain another constraint. AI handling more exceptions may reduce waiting, but may also generate more proposals needing verification. After handing tasks to machines, if recheck, rework, error-explanation costs exceed all gains from time, quality, risk improvement → reconstruction loses economic sense. For work where errors hard to detect, consequences hard to remedy, even smooth tech demos justify retaining stricter centralized control.
These alternative explanations mean "forced" cannot be universal diagnosis. If model upgrade alone improves a stable task, enterprise can directly capture gains; if demand insufficient, redistributing decision rights won't auto-increase orders. Only when reliable new capability exists, and existing division of labor, authorization, collaboration become clear bottlenecks, does the article's proposed relation adjustment directly respond.
Enterprises therefore need to observe same scenario at three levels: task layer — processing/wait time shortened? errors/rework changed? outcome layer — delivery, quality, service promises fulfilled? business layer — new revenue, real costs, customer relations, cash occupancy improved, including model use, system maintenance, supervision, training, transition costs? Three levels can be out of sync; cannot pick best-looking one to declare success.
When conditions allow, compare teams with similar work difficulty and investment, or phase implementation on similar scenarios, while recording demand, people, business condition changes. Such comparison still may not eliminate all interference, but at least lets enterprise distinguish: result improvement from model upgrade, added headcount, or an authorization/collaboration adjustment? Human takeover rates and other process signals must be understood under comparable task difficulty, quality, risk exposure. Finding how bottlenecks shift gives basis for next investment.
Daily operations have more intuitive signals: customer requests reduce reliance on ad-hoc leadership coordination? new teams independently reuse already-precipitated capabilities? after relaxing action permissions, quality and risk still within acceptable range? Signals must be viewed with same-work difficulty, actual investment, results. More agents, more process reconstructions, even lower human takeover rates — none alone proves organization improved.
Stop conditions should be predefined: if cross-dept waiting doesn't decrease, supervision/coordination persistently increases → check design overweight; if frontline repeatedly crosses professional bottom lines → tighten permissions and scope; if only original team sustains results → cannot treat pilot as replicable capability. Conversely, if fixing interface or implementing existing authorization achieves same result → no need to expand reconstruction for a new label.
On organizational form: AI may support frontline autonomy OR make headquarters centralized analysis/decision easier. Enterprise should test which arrangement fits own tasks, capabilities, risks — not treat fewer layers, more agents as directionally correct. Mycelium organization's strong core/agile front is one answer to this dilemma; effectiveness still needs real-practice validation.
Let New Capabilities Enter Real Responsibility Relations
Return to that customer request for early delivery. Worthwhile change: enterprise timely finds credible facts, lets right people and digital capabilities enter work, forms decisions within authority, executes within professional boundaries, verifies with business evidence. Customer gets deliverable answer; employees know their judgment scope and escalation path; leaders can explain why accept or reject this request.
From steam (power revolution) to electricity (energy revolution) to today's compute revolution, basic capability expansion keeps changing production possibilities and drives people to rearrange collective work ways. Factory system, production layout, information flow evolution all occurred in tech/org/skills/market interplay. Switching source improves existing work; reconstructing production around new capability demands deeper business and relation adjustments.
AI gives enterprises conditions to rearrange part of analysis, option formation, task execution — letting people and AI complete tasks with new division of labor. This is its qualitative significance in the compute revolution. Resulting reconstruction pressure must be answered by enterprises through concrete authority/responsibility choices. After buying capability: who uses it, what decisions allowed, how verified, who bears cost, how gains shared — these cannot be delivered with software accounts.
AI opens space to reorganize knowledge work; enterprise must decide how capability, power, responsibility, interests re-correspond. Starting from valuable work, building reliable shared capabilities in ongoing operations, giving participants corresponding growth opportunities and dignity — only then can new productivity enter production relations the enterprise can sustain long-term.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Digital Planet
Data is a company's core asset, and digitalization is its core strategy. Digital Planet focuses on exploring enterprise digital concepts, technology research, case analysis, and implementation delivery, serving as a chief advisor for top‑level digital design, strategic planning, service provider selection, and operational rollout.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
