Skip to main content
Ideas / Research & Design / 10.22.2026

Programming for the AI Transition: Why Readiness Assessment Belongs in Lab Design

Bryan Hall Washington University in St Louis Laser lab

Research buildings are programmed from the present, but they operate in the future. A building that breaks ground in 2026 will be occupied in 2029 and in active service through 2050 and beyond. The decisions made during programming — power capacity, structural bay dimensions, HVAC zoning, network infrastructure, space mix — are largely irreversible once construction documents are complete. Changing them later is expensive, disruptive, and often technically infeasible.

For most of the last 50 years, this mismatch was manageable. Laboratory science evolved incrementally, and a well-designed research building from 1995 could accommodate the science of 2010 with modest renovation. The fundamental infrastructure assumptions — how much power a lab needs, how researchers use space, what the ratio of bench to office should be — shifted slowly enough that buildings aged gracefully.

That is no longer true. Artificial intelligence is restructuring laboratory science faster than any previous technology transition, and the pace of change is discontinuous, not incremental. A materials science group that was 20% computational five years ago may be 70% computational today, running autonomous closed-loop experiments around the clock in equipment that draws ten times the power of the bench it replaced. If programming conversations don’t surface these changes explicitly and early, buildings get designed for a version of science that no longer exists.

The Four Dimensions That Matter

AI readiness is not a binary. Virtually every research program uses AI in some form. The programming questions are where in the research workflow AI is operating, how deeply it is integrated into physical infrastructure, and how fast that integration is expected to deepen over the building’s useful life. For design purposes, those questions map to four infrastructure dimensions.

A diagram of the four diagrams for AI drivers

Power density. Traditional lab programming assumes 15–25 watts per square foot. AI-integrated labs — autonomous systems, robotic platforms, GPU-accelerated computing — routinely require 50–150 watts per square foot in compute-intensive zones. This is not a rounding error; it demands fundamentally different service, distribution, and backup infrastructure. A building programmed to traditional assumptions and asked to support an autonomous lab will face a costly electrical retrofit within its first decade.

Continuous operation. Traditional research buildings are designed for occupied hours of operation — HVAC and cooling sized for a ten-hour day, five days a week. Autonomous labs and GPU clusters run 24/7/365. A building with cooling loads designed for occupied hours will overload its computing infrastructure within months of commissioning. This is the most common immediate infrastructure failure in recently completed research buildings.

Data infrastructure. A single session of AI-assisted confocal microscopy can generate terabytes of imaging data. Genomics pipelines, autonomous experiment logs, and simulation outputs compound that volume further. The building needs fiber-to-bench connectivity, high-bandwidth backbone connections to campus HPC or cloud infrastructure, and on-site storage sized to research data — not administrative network assumptions.

Space mix. The ratio of bench to computational research space is shifting in every discipline. In genomics, bioinformatics, computational chemistry, and simulation-based engineering, computational work has become the dominant activity, with bench time often below 30% of total research hours. A building programmed to a 70/30 bench-to-office ratio for a program operating at 40/60 will be functionally misaligned from day one.

Why the Conversation Doesn't Happen on Its Own

The failure mode is organizational, not technical. University research facilities involve VPs of Research, Facilities Directors, IT leadership, department chairs, and individual PIs who rarely share a common vocabulary for infrastructure requirements — and almost never have a structured forum to align before programming begins. The result is predictable.

PIs describe science, not infrastructure. Asked what their building needs, researchers describe experiments and discoveries. They do not describe power densities, cooling loads, or bandwidth requirements. They shouldn’t have to — but without a translation layer, those requirements never enter the program. Facilities teams, without explicit guidance, apply historical benchmarks calibrated for buildings that predate the current AI transition. Those benchmarks are systematically inadequate. And in most institutions, research computing and building systems report through different structures entirely — when they haven’t aligned, buildings get designed without the full picture. This is not an edge case; it is the norm.

A structured readiness assessment creates the forum these conversations require. It brings the right stakeholders together, asks the questions that surface infrastructure requirements, and generates the shared understanding that programming decisions need.

Where the Urgency is Greatest

AI readiness assessment is relevant across all science and engineering typologies, but urgency varies. Understanding the reasons why will help design teams calibrate their programming conversations.

AI Scientific Readiness Spectrum Diagram

Physics and materials science lead the transition for structural reasons. Physical systems obey known laws; the search space, while large, is bounded and navigable. Instruments like X-ray diffractometers, electron microscopes, and neutron scattering beamlines generate large volumes of structured, high-quality numerical data that AI processes efficiently. Computational methods — density functional theory, molecular dynamics — have reached a fidelity where AI trained on simulation data transfers reliably to physical experiments. And synthesis and characterization workflows are physically compatible with robotic execution: the operations are repeatable, the tolerances manageable, the environment controlled. The result is that fully autonomous closed-loop laboratories like ORNL’s INTERSECT and Berkeley’s A-Lab are already operational and producing peer-reviewed results. This is not a future state. Buildings programmed today for physics or materials science programs should treat continuous operation, data-center power densities, and robotic clearance requirements as baseline program elements, not optional upgrades.

Chemistry occupies a productive middle ground. AI tools now propose multi-step synthesis routes for target molecules in minutes, compressing what was once weeks of literature review. Self-driving chemistry platforms optimize reaction conditions — temperature, solvent, concentration, catalyst — through iterative robotic experimentation. But chemistry is harder to automate than materials science: hazardous reagents, multi-phase systems, sensitivity to trace impurities and handling technique, and the difficulty of scaling AI-optimized conditions from milligram to gram quantities all add complexity. The design implication is significant — autonomous chemistry labs require sophisticated integration of fume hood and ventilation systems with robotic platforms, chemical storage automation, and waste handling. The infrastructure ask is higher, and the programming conversation needs to be correspondingly specific.

Biology presents the most fundamental challenges, but the discipline is not monolithic. Dry biology — computational biology, genomics, proteomics — has been effectively AI-native for years. AlphaFold’s resolution of the protein structure prediction problem was a landmark demonstration; genomics pipelines are now almost entirely AI-augmented; drug target identification via AI mining of genomic and proteomic databases is standard practice. These workflows are compute-intensive but physically simple: they happen in servers, not at benches. The programming implication is straightforward — more compute infrastructure, less wet bench — and it represents a significant departure from historical space programs for biology buildings.

Wet biology is a different story. Living systems are inherently variable in ways that materials science is not: cell lines drift, animal models vary, tissue samples are heterogeneous. That variability is not noise to be filtered — it is often scientifically meaningful, and AI systems trained on one batch of reagents may not generalize to the next. Contamination risk constrains robotic systems in ways that materials science workflows are not. Many biological experiments unfold over days or weeks, foreclosing the fast iteration cycles that make AI so powerful in other disciplines. And regulatory frameworks — IBC, IACUC, BSL classifications — build human oversight requirements into the structure of biological research in ways that limit how much autonomy can be granted to automated systems. The programming implication is not that wet biology buildings don’t need AI readiness assessment — they do — but that the assessment needs to distinguish carefully between dry and wet workflows, and design accordingly.

The Cost of Getting It Wrong

The consequences are concrete. Adding electrical capacity to a completed building typically runs $150–$400 per square foot of affected area, with significant disruption to occupied research space. Emergency cooling retrofits for overheating compute rooms compromise architectural integrity and operational continuity. A building with too much bench and too little computational space cannot be easily reconfigured — fume hoods, BSL-rated construction, and plumbing don’t move. And a building that can’t support the infrastructure a prospective PI needs becomes a recruiting liability, with costs that are real if difficult to quantify.

The asymmetry matters: building infrastructure headroom into initial construction costs a fraction of the retrofit cost. The marginal investment in AI-ready infrastructure during design is almost always justified by lifecycle analysis.

What Changes When Readiness Is Assessed Early

When readiness assessment is integrated into programming — before space programs are fixed, structural bays are set, and systems are sized — infrastructure gets right-sized from the start. Space programs reflect actual research workflows rather than historical ratios. Flexibility is designed in rather than bolted on, with modular casework, oversized utility chases, and adaptable HVAC zoning concentrated where the research trajectory is most uncertain.

Equally important, clients make decisions they otherwise defer. The most valuable output of a readiness assessment is often the questions it forces clients to answer: Has the institution committed to on-premise HPC or cloud computing? Have IT and facilities aligned on network requirements? Which PIs are planning autonomous lab deployments in the next five years? These decisions have major design implications. Without a structured process to surface them, they get deferred until they become constraints rather than choices.

And the design team earns something harder to quantify but more durable: the credibility of a firm that understands research strategy, not just building systems. That positioning compounds — in client relationships, in referrals, and in the quality of the buildings that result.

The Calculation

The building being programmed today will be in service in 2045. The research it houses will look nothing like the research being conducted when it was designed. That has always been true — but the pace of change has never been faster, and the infrastructure consequences of getting it wrong have never been more expensive.

AI readiness assessment is not a prediction of the future. It is a structured process for understanding where the research trajectory is already pointing, and designing buildings that can follow it. The questions it asks are not technically complex. They are organizationally difficult: they require the right stakeholders in the same room, asking questions that cross institutional boundaries, and committing to answers that drive design decisions.

That is exactly what programming is for.

The cost of not asking these questions is paid in retrofits, in stranded equipment, in recruiting losses, and in buildings that constrain the research they were built to support. The cost of asking them is a structured conversation before schematic design begins.

That is not a difficult calculation.

Rainey Hufstetler is a senior associate architect at Ayers Saint Gross with 25 years of lab planning expertise focusing on the holistic laboratory ecosystem. 

 

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×