The AI Boom as Construction’s Lasting Fix: Engineering the Modern Build

The artificial intelligence boom is no longer confined to data centers, research labs, and consumer software. It is now pressing hard against one of the most stubbornly analog industries on earth: construction. A Reuters Breakingviews commentary argues that the AI surge could deliver a lasting fix for a sector long described as strained, and the claim deserves serious engineering scrutiny rather than reflexive optimism. Beneath the headline sits a genuine structural story about capital, compute, and concrete.

Construction has historically suffered from thin margins, fragmented supply chains, and productivity growth that lags nearly every other major industry. AI offers something rare here: a demand signal so large that it forces modernization of the physical layer itself. Hyperscalers need land, power, cooling, and steel at unprecedented speed, and that pressure cascades directly into how buildings get designed, permitted, and assembled.

This analysis unpacks the commentary's core message, then translates it into concrete software and systems engineering practice. We examine how AI-driven demand reshapes construction economics, where automation genuinely helps, and which technical patterns engineers should master. Expect code, data tables, and architectural reasoning rather than vague futurism.

The Core Argument: AI Demand as a Structural Catalyst for Construction

The commentary's central claim is deceptively simple: the AI boom creates sustained, capital-intensive demand that construction cannot ignore. Unlike speculative cycles, AI infrastructure spending is anchored by real compute requirements, long-term contracts, and hyperscaler balance sheets. That anchoring gives construction firms a rare planning horizon measured in years rather than quarters.

When demand becomes predictable, investment in automation becomes rational. A contractor will not buy robotics for a one-off project, but will for a decade-long pipeline of data centers. This is the mechanism the commentary implies: AI does not merely fund construction, it restructures the incentives that govern how construction modernizes.

From Speculative Cycle to Durable Infrastructure Pipeline

Data center construction differs fundamentally from commercial real estate because the end product is a revenue-generating machine. Every megawatt of capacity translates into billable compute, which means delays carry immediate financial penalties. This economic pressure forces contractors toward schedule compression techniques that were previously optional.

Prefabrication, modular power skids, and standardized cooling loops all reduce on-site labor variance. AI demand rewards repeatability, and repeatability is precisely what enables industrial-scale automation. The pipeline itself becomes the business case for change.

Consider how a scheduling optimizer might model this pipeline. The following Python example uses linear programming concepts to allocate crews across concurrent data center builds while respecting hard deadlines.

from dataclasses import dataclass
from typing import List

@dataclass
class Project:
    name: str
    megawatts: float
    deadline_weeks: int
    crew_weeks_required: float

def total_crew_weeks(projects: List[Project]) -> float:
    """Aggregate labor demand across a data center pipeline."""
    return sum(p.crew_weeks_required for p in projects)

def utilization(projects: List[Project], available_crew_weeks: float) -> float:
    demand = total_crew_weeks(projects)
    if available_crew_weeks <= 0:
        raise ValueError("Available crew weeks must be positive")
    return demand / available_crew_weeks

pipeline = [
    Project("DC-Alpha", 120.0, 78, 4200.0),
    Project("DC-Bravo", 80.0, 60, 2600.0),
    Project("DC-Charlie", 200.0, 104, 7100.0),
]

print(f"Total demand: {total_crew_weeks(pipeline):.0f} crew-weeks")
print(f"Utilization: {utilization(pipeline, 15000.0):.2%}")

The model is deliberately simple, but it exposes the core tension: capacity is finite while the pipeline compounds. When utilization approaches or exceeds one, contractors must either expand crews or automate tasks. AI demand pushes utilization upward, making automation economically unavoidable.

This is why the commentary frames AI as a lasting fix rather than a temporary boost. The fix is not a single technology; it is a persistent demand condition that makes modernization self-sustaining.

Why "Strained" Is an Engineering Diagnosis, Not Rhetoric

Describing construction as strained is not editorial flourish; it reflects measurable constraints. Skilled labor shortages, permitting bottlenecks, and material lead times all impose hard limits on throughput. These are queueing problems, and queueing problems obey mathematics whether or not managers acknowledge them.

Little's Law states that the average number of items in a system equals arrival rate multiplied by average time in system. For construction, this means that if arrival rate rises while service time stays constant, work-in-progress explodes.

Here ##L## is work in progress, ##lambda## is project arrival rate, and ##W## is average project duration. AI demand increases ##lambda## dramatically. Unless ##W## falls through automation and prefabrication, the system saturates and delays compound nonlinearly.

This mathematical framing clarifies why incremental improvements fail. A ten percent productivity gain cannot absorb a tripling of demand. Only structural change in ##W##, achieved through design automation and off-site manufacturing, restores stability.

Where AI Actually Helps: Design, Scheduling, and Supply Chains

AI's contribution to construction is not a robot that lays bricks. It is a stack of optimization, prediction, and generative design tools that compress decision latency. Each compressed decision removes days from a schedule, and days compound across thousands of interdependent tasks.

Generative design explores thousands of structural and MEP layouts in hours, surfacing options no human team could evaluate manually. Predictive models forecast material price volatility and labor availability, allowing procurement to hedge intelligently. Scheduling engines resolve resource conflicts continuously rather than weekly.

Generative Design and Parametric Optimization

Parametric design treats a building as a set of constraints and objectives rather than a fixed drawing. AI search algorithms then explore the design space to minimize cost, embodied carbon, or schedule risk. This is optimization under constraint, a well-understood computational problem.

The following example demonstrates a simple genetic-style search over structural bay spacing, balancing steel tonnage against constructability.

import random
from typing import List, Tuple

def steel_tonnage(bay_spacing_m: float, span_m: float, floors: int) -> float:
    """Rough estimate of structural steel mass for a regular grid."""
    bays_x = max(1, int(span_m / bay_spacing_m))
    bays_y = bays_x
    columns = (bays_x + 1) * (bays_y + 1) * floors
    beams = bays_x * (bays_y + 1) * floors + bays_y * (bays_x + 1) * floors
    return columns * 0.9 + beams * 0.35

def constructability_penalty(bay_spacing_m: float) -> float:
    """Penalize spacings that are hard to prefabricate or crane."""
    if bay_spacing_m < 6.0:
        return 50.0
    if bay_spacing_m > 12.0:
        return 30.0
    return 0.0

def fitness(bay_spacing_m: float) -> float:
    return steel_tonnage(bay_spacing_m, 60.0, 4) + constructability_penalty(bay_spacing_m)

population: List[float] = [random.uniform(5.0, 14.0) for _ in range(40)]

for generation in range(60):
    population.sort(key=fitness)
    survivors = population[:10]
    offspring: List[float] = []
    while len(offspring) < 30:
        parent = random.choice(survivors)
        child = parent + random.gauss(0, 0.4)
        offspring.append(min(14.0, max(5.0, child)))
    population = survivors + offspring

best = min(population, key=fitness)
print(f"Optimal bay spacing: {best:.2f} m")
print(f"Estimated steel: {steel_tonnage(best, 60.0, 4):.1f} tonnes")

This is not a substitute for structural engineering judgment, but it is a powerful filter. It eliminates obviously poor configurations before human review, freeing engineers to focus on genuinely difficult trade-offs. That is the realistic role of AI in design.

When thousands of such optimizations run across a portfolio, the aggregate schedule and cost savings become material. This is how AI delivers a lasting fix rather than a marginal improvement.

Predictive Supply Chain and Procurement Intelligence

Material lead times are the hidden schedule killers in construction. A transformer ordered late can delay energization by a year, stranding millions in idle capital. Predictive models that forecast lead times and prices convert procurement from reactive to anticipatory.

These models ingest supplier data, port congestion metrics, commodity indices, and historical delivery performance. The output is a probabilistic lead-time distribution rather than a single number, which is far more useful for planning.

import statistics
from typing import List, Dict

def lead_time_distribution(samples: List[int]) -> Dict[str, float]:
    """Summarize a supplier lead-time sample into planning statistics."""
    if not samples:
        raise ValueError("Samples required")
    return {
        "mean": statistics.mean(samples),
        "median": statistics.median(samples),
        "p90": sorted(samples)[int(0.9 * (len(samples) - 1))],
        "stdev": statistics.pstdev(samples),
    }

transformer_lead_times = [180, 210, 240, 300, 365, 400, 420, 365, 300, 270]

stats = lead_time_distribution(transformer_lead_times)
for key, value in stats.items():
    print(f"{key}: {value:.1f} days")

buffer_days = stats["p90"] - stats["median"]
print(f"Recommended schedule buffer: {buffer_days:.0f} days")

Planning against the ninetieth percentile rather than the mean is a discipline that separates resilient projects from fragile ones. AI makes this discipline computationally cheap, which is precisely why adoption accelerates under demand pressure.

The commentary's optimism is defensible here. When the cost of prediction falls, the optimal behavior shifts toward hedging and early procurement, reducing systemic schedule variance.

Automation, Robotics, and the Physical Layer of AI Infrastructure

Software optimization has limits; at some point, physical work must happen. Robotics and automation address the physical layer, but their economics depend entirely on repetition. Data centers, with their standardized racks, power skids, and cooling modules, are unusually robot-friendly compared to bespoke architecture.

Off-site manufacturing converts on-site labor into factory labor, where automation, quality control, and parallelization are far easier. Modules arrive tested and sequenced, reducing on-site hours and rework. This is industrial logic applied to construction, and AI demand makes it viable at scale.

Modular Assembly and Off-Site Manufacturing

Modular construction shifts work from a chaotic site to a controlled factory. The factory can run multiple shifts, use fixed robotics, and maintain consistent tolerances. Site work becomes assembly rather than fabrication, which is dramatically faster and more predictable.

The following example models the throughput advantage of parallel factory lines versus sequential site construction.

from dataclasses import dataclass

@dataclass
class Module:
    name: str
    factory_hours: float
    site_hours: float

def sequential_site_time(modules: list) -> float:
    return sum(m.site_hours for m in modules)

def parallel_factory_time(modules: list, lines: int) -> float:
    total_factory = sum(m.factory_hours for m in modules)
    return total_factory / lines

modules = [
    Module("Power skid", 120.0, 200.0),
    Module("Cooling loop", 90.0, 160.0),
    Module("Rack row", 60.0, 110.0),
    Module("Fire suppression", 40.0, 80.0),
]

site = sequential_site_time(modules)
factory = parallel_factory_time(modules, 3)
print(f"Sequential site hours: {site:.0f}")
print(f"Parallel factory hours: {factory:.0f}")
print(f"Compression ratio: {site / factory:.2f}x")

The compression ratio is the entire business case. When factory lines run in parallel, total duration collapses even though total labor hours may be similar. Time, not labor, is the scarce resource in AI infrastructure delivery.

This is why the commentary's framing holds: AI demand creates the repetition that makes modularization profitable, and modularization delivers the schedule certainty AI companies require.

Robotics Economics and Task Selection

Not every construction task justifies a robot. Robotics pays off when tasks are repetitive, high-precision, dangerous, or labor-constrained. Data center construction concentrates all four characteristics in specific work packages such as cable pulling and rack installation.

Task selection is therefore an economic optimization, not a technology showcase. The following scoring function ranks candidate tasks by automation suitability.

from dataclasses import dataclass

@dataclass
class Task:
    name: str
    repetition: float      # 0-1
    precision_need: float  # 0-1
    hazard: float          # 0-1
    labor_scarcity: float  # 0-1

def automation_score(task: Task) -> float:
    weights = {
        "repetition": 0.35,
        "precision_need": 0.25,
        "hazard": 0.20,
        "labor_scarcity": 0.20,
    }
    return (
        task.repetition * weights["repetition"]
        + task.precision_need * weights["precision_need"]
        + task.hazard * weights["hazard"]
        + task.labor_scarcity * weights["labor_scarcity"]
    )

tasks = [
    Task("Cable pulling", 0.9, 0.6, 0.5, 0.8),
    Task("Rack installation", 0.85, 0.8, 0.3, 0.7),
    Task("Custom facade work", 0.2, 0.7, 0.6, 0.4),
    Task("Site surveying", 0.5, 0.9, 0.2, 0.5),
]

for task in sorted(tasks, key=automation_score, reverse=True):
    print(f"{task.name}: {automation_score(task):.3f}")

Ranking tasks this way prevents the common failure mode of automating the most visible task rather than the most valuable one. Cable pulling and rack installation score highest, which matches real-world deployment patterns in hyperscale builds.

Robotics adoption then follows a rational path: start where scores are highest, prove reliability, and expand. AI demand provides the volume that justifies each incremental step.

Data, Digital Twins, and the Software Stack Behind Modern Builds

Every automated decision depends on data quality. Construction generates enormous volumes of telemetry, from crane load sensors to concrete maturity monitors. Without a coherent data architecture, AI models train on noise and produce unreliable guidance.

Digital twins provide the unifying abstraction: a live, queryable model of the physical asset. They connect design intent, construction progress, and operational performance into a single source of truth. AI then operates on that truth rather than on fragmented reports.

Building the Data Pipeline for Construction Telemetry

A construction data pipeline must handle high-frequency sensor streams, low-frequency progress updates, and document metadata. The architecture resembles industrial IoT more than traditional enterprise software, demanding streaming ingestion and time-series storage.

The following example illustrates a simple ingestion and validation routine for sensor telemetry before it reaches a digital twin.

from dataclasses import dataclass
from datetime import datetime
from typing import Optional

@dataclass
class Reading:
    sensor_id: str
    timestamp: datetime
    value: float
    unit: str

def validate_reading(reading: Reading, min_value: float, max_value: float) -> Optional[Reading]:
    """Reject physically impossible readings before they pollute the twin."""
    if reading.value < min_value or reading.value > max_value:
        return None
    if reading.timestamp > datetime.utcnow():
        return None
    return reading

def ingest(batch: list, min_value: float, max_value: float) -> list:
    accepted = []
    for reading in batch:
        valid = validate_reading(reading, min_value, max_value)
        if valid is not None:
            accepted.append(valid)
    return accepted

raw = [
    Reading("crane-01", datetime(2026, 9, 14, 4, 0), 42.5, "tonnes"),
    Reading("crane-01", datetime(2026, 9, 14, 4, 1), 9999.0, "tonnes"),
    Reading("concrete-07", datetime(2026, 9, 14, 4, 2), 28.0, "MPa"),
]

clean = ingest(raw, 0.0, 500.0)
print(f"Accepted {len(clean)} of {len(raw)} readings")

Validation at the edge prevents garbage from propagating into models that drive safety-critical decisions. This is unglamorous engineering, but it is the foundation on which every credible AI application in construction rests.

Once data is trustworthy, digital twins enable simulation, what-if analysis, and predictive maintenance. These capabilities compound over the asset lifecycle, extending AI's value far beyond the initial build.

Interoperability Standards and Model Exchange

Construction software has historically been fragmented, with each discipline using incompatible formats. Interoperability standards such as IFC allow models to move between tools without lossy translation. AI systems depend on this fluidity to reason across domains.

The following example demonstrates parsing and normalizing a simplified IFC-like entity list into a unified schema.

from typing import Dict, List

def normalize_entities(entities: List[Dict[str, str]]) -> List[Dict[str, str]]:
    """Map heterogeneous entity records into a canonical schema."""
    canonical = []
    for entity in entities:
        canonical.append({
            "global_id": entity.get("GlobalId") or entity.get("id") or "unknown",
            "type": entity.get("Type") or entity.get("ifcType") or "IfcProduct",
            "name": entity.get("Name") or entity.get("label") or "",
            "storey": entity.get("Storey") or entity.get("level") or "unassigned",
        })
    return canonical

raw_entities = [
    {"GlobalId": "1A2B", "Type": "IfcBeam", "Name": "B-101", "Storey": "L02"},
    {"id": "3C4D", "ifcType": "IfcColumn", "label": "C-205", "level": "L03"},
]

for record in normalize_entities(raw_entities):
    print(record)

Normalization is the quiet enabler of cross-discipline AI. Without it, every model requires bespoke preprocessing, and maintenance costs explode. With it, models become reusable assets across projects and portfolios.

This reusability is what transforms AI from a project expense into a platform capability. The commentary's "lasting fix" language maps directly onto this platform economics.

Economic and Workforce Implications of an AI-Driven Construction Shift

Automation reshapes labor demand rather than eliminating it. The mix shifts from manual execution toward machine supervision, data interpretation, and system integration. This transition requires deliberate workforce development, not passive optimism.

Firms that invest in retraining capture the productivity gains; firms that do not face a widening skills gap. The economics are unforgiving because AI infrastructure timelines leave little room for slow adaptation.

Capital Allocation and Return on Automation

Automation investments compete for capital against traditional equipment and working capital. A rigorous return model must account for utilization, residual value, and schedule savings, not just labor displacement.

The following example computes a simple payback period for a construction robotics deployment.

def payback_period(capex: float, annual_savings: float, maintenance: float) -> float:
    """Years required to recover an automation investment."""
    net_savings = annual_savings - maintenance
    if net_savings <= 0:
        raise ValueError("Investment never pays back")
    return capex / net_savings

def npv(capex: float, annual_savings: float, maintenance: float, years: int, rate: float) -> float:
    net = annual_savings - maintenance
    value = -capex
    for year in range(1, years + 1):
        value += net / ((1 + rate) ** year)
    return value

capex = 2_400_000.0
savings = 900_000.0
maintenance = 150_000.0

print(f"Payback: {payback_period(capex, savings, maintenance):.2f} years")
print(f"5-year NPV: {npv(capex, savings, maintenance, 5, 0.09):,.0f}")

When payback falls under three years, automation becomes an easy boardroom decision. AI demand compresses payback by increasing utilization, which is the mechanism that makes the commentary's thesis financially coherent.

Capital discipline still matters. Over-automating low-volume tasks destroys value, so portfolio-level analysis must precede any deployment decision.

Workforce Transition and New Engineering Roles

New roles emerge as automation spreads: robotics technicians, digital twin engineers, and construction data analysts. These roles blend domain knowledge with software skills, and they are currently undersupplied relative to demand.

Training pipelines must therefore combine trade fundamentals with programming, statistics, and systems thinking. The following example outlines a competency scoring model for workforce planning.

from dataclasses import dataclass

@dataclass
class Worker:
    name: str
    trade_skill: float      # 0-1
    software_skill: float   # 0-1
    data_skill: float       # 0-1

def readiness(worker: Worker) -> float:
    return (
        worker.trade_skill * 0.4
        + worker.software_skill * 0.35
        + worker.data_skill * 0.25
    )

def training_gap(worker: Worker, target: float = 0.75) -> float:
    return max(0.0, target - readiness(worker))

crew = [
    Worker("A. Mensah", 0.9, 0.3, 0.2),
    Worker("R. Okafor", 0.7, 0.6, 0.5),
    Worker("L. Chen", 0.6, 0.8, 0.7),
]

for worker in crew:
    print(f"{worker.name}: readiness={readiness(worker):.2f}, gap={training_gap(worker):.2f}")

Quantifying readiness gaps turns vague training ambitions into targeted programs. Workers with strong trade skills but weak software skills need different interventions than the reverse, and budgets should reflect that distinction.

This is how the industry converts an AI-driven demand shock into durable capability rather than a temporary labor crunch.

Risks, Limits, and the Boundaries of the AI Construction Thesis

Every compelling thesis has boundaries, and the AI construction narrative is no exception. Physical constraints, regulatory friction, and energy availability can all throttle progress regardless of software sophistication. Ignoring these limits produces brittle strategies.

The commentary's optimism should therefore be read as directional rather than absolute. AI improves the trajectory of construction productivity, but it does not repeal thermodynamics, permitting law, or grid capacity.

Physical and Regulatory Bottlenecks

Power availability is the sharpest constraint. A data center without energized capacity is an expensive shell, and grid interconnection queues can stretch for years. No amount of AI optimization accelerates a transformer that has not been manufactured.

Regulatory approval adds another layer of irreducible latency. Environmental review, zoning, and safety inspections follow statutory timelines that software cannot compress. These are genuine limits on how fast AI infrastructure can be built.

from dataclasses import dataclass

@dataclass
class Bottleneck:
    name: str
    duration_months: float
    compressible: bool

def critical_path(bottlenecks: list) -> float:
    """Sum durations along the critical path, respecting compressibility."""
    total = 0.0
    for item in bottlenecks:
        if item.compressible:
            total += item.duration_months * 0.7
        else:
            total += item.duration_months
    return total

path = [
    Bottleneck("Grid interconnection", 24.0, False),
    Bottleneck("Transformer manufacturing", 12.0, False),
    Bottleneck("Site civil works", 8.0, True),
    Bottleneck("MEP fit-out", 10.0, True),
]

print(f"Critical path: {critical_path(path):.1f} months")

This model shows why software optimism must be tempered. Even aggressive compression of compressible tasks leaves the incompressible ones dominating the schedule. Strategy must target the truly binding constraints.

Recognizing this distinction prevents wasted investment on automation that cannot move the critical path. It also clarifies where policy intervention matters most.

Model Risk and Over-Automation Failure Modes

AI models can fail silently, producing confident but wrong recommendations. In construction, such failures carry safety and financial consequences that dwarf typical software bugs. Robust validation and human oversight are non-negotiable.

The following example implements a simple guardrail that flags model outputs deviating beyond historical bounds.

import statistics
from typing import List

def guardrail(prediction: float, history: List[float], z_limit: float = 3.0) -> str:
    """Flag predictions that fall outside expected statistical bounds."""
    if len(history) < 5:
        return "insufficient_history"
    mean = statistics.mean(history)
    stdev = statistics.pstdev(history)
    if stdev == 0:
        return "no_variance"
    z_score = (prediction - mean) / stdev
    if abs(z_score) > z_limit:
        return f"flagged_z={z_score:.2f}"
    return "accepted"

historical_durations = [42, 45, 44, 47, 43, 46, 45, 44, 48, 43]
print(guardrail(44.0, historical_durations))
print(guardrail(120.0, historical_durations))

Guardrails convert silent failures into visible exceptions, which is exactly what safety-critical systems require. They are cheap to implement and dramatically reduce the blast radius of model error.

Over-automation is the mirror risk: removing human judgment where context matters more than speed. The correct posture is augmentation, with humans retaining authority over irreversible decisions.

Strategic Takeaways for Engineers and Technology Leaders

The commentary's core message survives technical scrutiny: AI demand creates durable pressure that forces construction modernization. That pressure is not a panacea, but it is a genuine structural catalyst with measurable economic consequences.

Engineers should treat construction as a domain ripe for systems thinking, where optimization, data engineering, and robotics converge. Leaders should fund platform capabilities rather than one-off pilots, because reuse is where value compounds.

Building Reusable Technical Capabilities

The highest-leverage investments are reusable: data pipelines, digital twin platforms, and optimization libraries. These assets serve many projects and improve with each deployment, unlike bespoke tools that decay after handover.

Standardization across projects also reduces integration cost and accelerates onboarding. The following example sketches a capability registry that tracks reuse across a portfolio.

from dataclasses import dataclass, field
from typing import List

@dataclass
class Capability:
    name: str
    domain: str
    reuse_count: int = 0
    projects: List[str] = field(default_factory=list)

    def deploy(self, project: str) -> None:
        self.reuse_count += 1
        self.projects.append(project)

registry = [
    Capability("Telemetry ingestion", "data"),
    Capability("Parametric optimizer", "design"),
    Capability("Lead-time forecaster", "procurement"),
]

registry[0].deploy("DC-Alpha")
registry[0].deploy("DC-Bravo")
registry[1].deploy("DC-Alpha")

for cap in registry:
    print(f"{cap.name}: reused {cap.reuse_count} times across {cap.projects}")

Tracking reuse makes platform value visible and defensible during budget reviews. It also reveals which capabilities deserve further investment and which should be retired.

This discipline converts scattered innovation into institutional advantage, which is the only form of progress that persists beyond a single boom cycle.

Measuring Impact and Avoiding Vanity Metrics

Impact measurement must focus on schedule compression, cost per megawatt, and safety incident rates. Vanity metrics such as model accuracy in isolation obscure whether real outcomes improved.

The following example computes a composite impact score weighted toward business outcomes rather than technical novelty.

def impact_score(schedule_gain: float, cost_gain: float, safety_gain: float) -> float:
    """Composite score where each input is a normalized 0-1 improvement."""
    weights = {"schedule": 0.45, "cost": 0.35, "safety": 0.20}
    return (
        schedule_gain * weights["schedule"]
        + cost_gain * weights["cost"]
        + safety_gain * weights["safety"]
    )

programs = {
    "Generative design": (0.30, 0.20, 0.05),
    "Modular assembly": (0.55, 0.40, 0.15),
    "Predictive procurement": (0.25, 0.35, 0.02),
}

for name, gains in programs.items():
    print(f"{name}: {impact_score(*gains):.3f}")

Weighting schedule and cost heavily reflects the reality that time-to-energization is the dominant economic variable in AI infrastructure. Safety remains essential but is often a constraint rather than a differentiator.

When impact is measured this way, investment decisions become transparent and defensible. The AI construction thesis then rests on evidence rather than enthusiasm.