Audio article narrated by OpenAI
The AEC industry has never been short of tools. What it has lacked is the discipline to stop adding them. Neil Meredith has spent twenty years watching this dynamic from every position in the delivery chain: as a design consultant, specialty fabricator, modular construction startup, and now as a general contractor. His career is not a story about building products in the conventional sense; it is a story about following one persistent problem through every room in the house and discovering that the problem moves with you. What follows is a conversation about what that kind of depth actually reveals, and what it would take to act on it.
About Neil Meredith
Neil Meredith recently joined DPR Construction, where he works at the intersection of prefab construction, technology and manufacturing. His career spans two decades across Gehry Technologies, specialty fabricators MG McGrath and Island Exterior Fabricators, and Assembly OSM, where he led the digital delivery and digital products teams for a venture-backed modular building startup that applied aerospace manufacturing discipline to high-rise residential construction. He holds a B.S. and M.Arch from the University of Michigan (Taubman College) and has taught computational design at Columbia GSAPP, the University of Michigan, and NJIT. Neil is a registered architect and has spoken widely at industry events such as Autodesk Design & Make and 3DEXPERIENCE World. Originally from outside Detroit, Michigan, he currently lives in Queens, New York.
—
“The thread connecting these seemingly different roles has been to just follow the problems.” Neil Meredith
—
The only credential that counts in fabrication
Most computational designers in AEC develop their practice on one side of the design-to-fabrication handoff. They build parametric models, produce geometric output, and hand off downstream documentation. What happens when the documentation reaches the shop floor or construction site is, in most firms, someone else’s problem.
Neil’s career was shaped by the recognition that this separation created a structural blind spot. At Gehry Technologies, working as a consultant on complex and technically demanding projects, the limitation became visible:
“There was always that 20–40% of a project where you had no idea what was actually happening in the real world. You work on a detailed prefab design, it gets released to the shop floor, and then what happens? You have no idea. As a consultant, you are narrowly focused on a specific part of the problem.”
So he moved to the fabricator side, because the next version of the problem was there. At MG McGrath and Island Exterior Fabricators, he learned what fabricators actually need from a model: not geometric expressiveness, but information they can use directly: tolerances, assembly sequences and assembly logic. Builders think in 3D and are prepared to work with 3D models, but the rest of the industry is not prepared to work with the liability structure that forces the handoff back to 2D.
The revelation came early. When asking for access to a 3D model at the start of a project, the typical response from designers was not refusal but a waiver: “You can have the model, but it’s for reference only. You can’t build from it.” The fabricators would then build from it anyway, because the 3D model was the best available information. The defensiveness had nothing to do with a belief that 2D documentation was more accurate. It was entirely about liability.
The scalability illusion affecting so many computational design workflows has a precise cause at this handoff: the model that could drive fabrication directly is held back by contractual structures that predate its existence.
The Assembly OSM hypothesis
The modular construction wave of the late 2010s and early 2020s was driven by a coherent, attractive thesis: apply the manufacturing discipline of aerospace and automotive manufacturing to construction. Tiered supplier networks, structured quality control, manufacturing-based systems, digital twins from design to factory to installation. Assembly OSM was one of the most intellectually rigorous versions of this hypothesis. Neil led the technology group.
The interdisciplinary team was, by his account, one of the genuine successes:
“Getting together groups of people from some really different disciplines in the same room was fascinating. We had people from design, supply chain, software development, manufacturing, some ex-aerospace and rocket company people, just people with wildly different backgrounds. After a while they start to understand how to work together, bringing different solutions to the same core problem — oh I see, we call it this in this manufacturing, but you’re trying to do this.”
The alignment that happens across disciplines when they share a problem long enough is exactly the kind of organisational capability that AEC most consistently fails to build. Assembly created it deliberately. That part worked.
What did not work was the product-market fit question. The customer side of the equation, specifically who pays for these buildings and under what conditions, was deferred. In Pattern Breakers, Mike Maples describes the test that distinguishes a genuine insight from a plausible-sounding one: can you find specific people who are desperate for you to build it? The Assembly OSM hypothesis was structurally sound. The customer was never identified before capital was deployed.
“It looked and operated like a tech company, but it did not have that agile feedback that you get from customers paying to solve a real-world problem. And I think if we had, we might have pivoted or changed course or navigated to some very different product decisions.”
The same failure mode recurs across the modular construction wave of that period: Katerra, Juno and a cohort of similar ventures. Not bad technology; a belief that a sufficiently good process would locate its own customer. Brian Potter, who tracked Katerra’s collapse in forensic detail, put it plainly: scaling physical infrastructure before validating product–market fit is the most expensive way to learn that the customer was never where you thought. Katerra built what may have been the largest CLT plant in the world. By the time it came online, the product direction had already changed. The factory outlived the thesis.
This is, at its core, a product–market fit problem, directly connected to the industry’s structural economics. Sean Young’s framing from an earlier conversation highlights the underlying reason: in manufacturing, the customer owns the factory, and improving output directly increases their revenue. In construction, where services are rendered for hire on someone else’s one-time asset, the incentive to invest in manufacturing-grade infrastructure belongs to nobody in particular. Assembly OSM and its peers were trying to build manufacturing-level supply chains in an industry structurally organised to resist exactly that investment. The thesis was right. The customer was never identified.
The problem with owning the model
The model ownership question surfaces in almost every AEC technology conversation. Who controls the data, who maintains the parametric relationships? Neil’s read on this is structural rather than technical, and it re-frames the question usefully:
“I see the problem less as who controls the data or owns the model, and more as an issue with how the business of construction or architecture works before projects even begin.”
The legal and organisational structure of a construction project is established before anyone has opened a modelling tool. Designers have their scope, the general contractor has theirs and subcontractors have theirs. The resulting fragmentation is not a failure of coordination. It is the designed outcome of a system built to distribute liability rather than optimise information flow. The only party that can see the full picture, schedule, cost, and performance across the whole is the owner. Everyone else is optimising their specific scope.
Buildings are, in their own way, extraordinarily complex objects. An aircraft is also complicated, but manufacturers build thousands of them. Each building is a one-off, has to be figured out from scratch each time, and involves a cast of dozens of organisations that are not in the habit of thinking of themselves as collectively producing a product. They produce their scope of work. The building emerges when all the scopes are complete.
Neil draws a distinction from industrial design that applies differently in an AEC context: in industrial design, a design is successful only if it solves a customer’s problems. Awards without commercial viability are considered a failure. In architecture, the inverse has historically been true: a firm can win awards for a building that was never fully leased, or be celebrated for a project that ran significantly over budget. The feedback loop that keeps consumer products honest does not operate in the built environment. The end user, the person who will live or work in the building, has almost no direct voice in how it gets made.
This absence shapes everything downstream. Computational design tools, however sophisticated, are applied to a delivery system that was never structured to ask whether the building works for the people who use it. That question belongs to industrial design. It has not, structurally, belonged to AEC. This is why the strange case of computational design tools persists even as the tools themselves improve: the most sophisticated parametric model still hits the wall of a project structure that was designed before it existed, for a customer who was never formally asked.
More sheets, less clarity
One of the sharper ironies in the digitisation of the AEC industry is that tools capable of producing more documentation have not led to better-informed projects. They have produced heavier drawing sets.
The UC Berkeley Art Museum and Pacific Film Archive (BAMPFA) project offered a counter-example. The building enclosure was a complex, twisted stainless-steel form designed by Diller Scofidio + Renfro. The shop drawing set was 14 pages, whereas hundreds of 2D details and drawing views would have been conventional. The approach was straightforward: use the 3D fabrication model directly, hold regular sessions with the project team, build quick physical mock-ups to show the detailing, and build trust through transparency rather than documentation volume.
“We used 3D models. We held multiple coordination meetings weekly where we’d use the 3D model live to show how the facade was going to come together and how we were fabricating it. I think building that trust, and communicating through the 3D model, helped everyone realize that we could execute the construction of such a challenging form.”
The fourteen-page set is not a failure of rigour. It is the result of asking a different question: not “what do we need to produce?” but “what does the fabricator actually need to build this and maintain design intent?” Coordinating around the model answered that question directly.
The irony of the opposite approach:
“With automation tools, you have the technical ability to produce more drawings and documentation than ever before. But creating those details does not necessarily mean they are a useful communication medium. It just means you have the ability to create more details.”
Joseph Tainter’s analysis of complex societies in The Collapse of Complex Societies offers a structural frame for this pattern. He argues that societies invest in complexity to solve problems, but each layer of complexity carries a maintenance cost. As the marginal return on added complexity declines, the cost of maintaining it continues to grow. The result is not a dramatic collapse but a gradual degradation: more effort is required to sustain the same output. AEC has been running this experiment for thirty years: more tools, more process, more documentation, more coordination, more review burden. Construction labour productivity in the US fell roughly 40% between 1970 and 2020. The tools multiplied; the output per hour did not.
At Assembly OSM, the response to this pattern was a discipline that is rarely practised and rarely discussed: you cannot introduce a new tool in the workflow unless you remove one, and potentially two. The instinct to accumulate is nearly universal. The discipline of removal is rare.
The ERP that never existed
Manufacturing has a boring but foundational piece of infrastructure that construction has never built: the enterprise resource planning system. ERP is not glamorous. It is inventory management, part numbering, routing, work scheduling and financial transactions, all in one platform. It is boring precisely because it is foundational: once it exists, you can build on top of it. Work can be routed. Quality can be tracked. Data can be structured enough to learn from.
“I think in AEC we still have a lot of vendor lock-in and stagnation in our current tool set. It’s hard to get things to talk to each other or create a consistent, scalable workflow, and this happens consistently across projects, year over year. We aren’t working with the best tools out there.”
Construction has accumulated 20 years of BIM-generated project data and lacks a structured way to access most of it. The data sits in disconnected tool outputs, random Excel files, workflows that were optimised for the project at hand and then abandoned. The recognition that the data exists and is inaccessible is growing, but the infrastructure to make it useful has not been built.
The closest analogy from another industry is Palantir’s Ontology: a semantic data layer that connects enterprise information into a meaningful graph, regardless of the source system. It allows organisations to ask structured questions of data that previously existed in disconnected silos. Construction needs something analogous: not another authoring tool or file-sharing layer, but a graph of project knowledge that persists across handoffs and accumulates intelligence over time. The data exists. The infrastructure to connect it does not. The company or open standard that builds that layer earns the right to operate as the ERP equivalent: the foundational system that makes everything else more useful.
The comparison Neil draws to Speckle is instructive: a platform that bridges multiple authoring tools and enables structured data to flow between them, rather than locking it into a single vendor’s ecosystem. The more interesting possibility, in an era of increasingly capable AI, is not just data flow but data translation: AI as the layer that interprets information across tools and formats that were never designed to communicate with each other. AEC companies are sitting on enormous amounts of project data (in Revit files, PDFs, coordination models, and field reports), but most of it remains stranded because the industry has never invested in APIs to make it accessible. In most mature software industries, accessible APIs are table stakes: the minimum expectation for any serious platform. In AEC, exposing structured project data via API is still the exception rather than the rule. Platform approaches that enable data flow across tools are more valuable than bespoke internal tools that solve only one team’s problems. This is also the argument in Transform computational teams for product success: without a clear strategy for how computational solutions are developed, maintained, and shared, the industry keeps rebuilding the same solutions in isolation.
AI and the collapse of the specialist gap
The computational designer role has been defined, for most of its existence, by a skills gap: the gap between the person who knows what needs automating and the person who can build the automation. Grasshopper, Dynamo, CATIA scripts, Python, they all sit on the specialist side of this gap. The person with the domain knowledge, the fabricator, the estimator, the project engineer, typically lacks the tooling fluency to act on what they know.
AI is collapsing that gap. Not in the way that press releases describe, but in a structural way: a 15-year-old can now open a browser, describe what they want a script to do, and have something functional returned in seconds. That same person, asked to open Grasshopper and wire up ten components, would not get there. The conversational interface is not just easier; it is a different kind of access. It is the same bet that Amir Dezfouli made explicit: every construction professional could already describe what they needed to be automated. The barrier was never understood. It was the distance between articulation and execution.
“I think the democratization of a lot of these design tools is a good thing. I think there’s always an awkward phase where people are learning and adapting to new technology.”
What he is excited about is an unexpected application: for example, a procurement team member building a web application for something they care about, and that no one on the technical team would have thought of. When a capability becomes broadly accessible, the most interesting uses come from people who were never supposed to be the users.
The risk that comes with democratisation, though, is not incompetence: it is the loss of craft. Chesky, reflecting on what Apple’s creative culture taught him, draws a distinction worth carrying into AEC: simplicity is not removing things. It is distilling something so fundamentally that you understand its essence. An engineer who uses AI to automate a workflow they barely understand produces faster output, not better output. The discipline that matters is not access to the tool; it is the judgment to know what should be simplified, what should be removed, and what the underlying structure actually requires. That judgment does not come from the AI. It comes from years of following the problem through its actual complexity.
The computational designer role does not disappear in this scenario. It shifts. The Grasshopper specialist, who is the only person who can execute a particular workflow, becomes the person who understands how all the workflows fit together, where the data needs to flow and what the platform needs to look like underneath. The role becomes more organisational and less craft-based:
“I think the type of work they might be doing will be different. Instead of asking how to create the best script that takes a certain input and updates a door schedule, it could become a broader application of technology that cuts across the organization or design workflow.”
This mirrors the shift that happened in software development when higher-level languages and frameworks reduced the barrier to coding: the specialist role did not disappear, but it moved up the abstraction stack. The question for AEC computational design is whether the organisations that employ these people are prepared to use them at that level, or whether they will continue to deploy them as workflow fixers for whatever broke this week.
Where complexity accumulates
The economic structure of construction, particularly in North America, creates a persistent misalignment between what technology is supposed to do and what the business model rewards. Variations and delays are not purely failures; they are, for significant parts of the delivery chain, where margin lives. A team that finishes ahead of schedule does not always capture the upside. The budget overrun is often where profit is extracted.
“The net result is things are getting more complicated. Workflows are getting more complicated. Buildings are getting more expensive. We need a way to be able to cut through some of this and just make things better, simpler. And you see the gains in manufacturing over the last 50 years and to see the buildings haven’t even approached that type of manufacturing-type gains yet. It’s a very stark contrast.”
The SpaceX principle runs directly counter to this. Musk’s engineering maxim, “the best part is no part, the best process is no process,” is a deletion mandate before it is anything else. Every surviving element must justify its existence. And if you’re not adding back 10% of what you removed, you’re not removing enough. AEC does the inverse. Contracts grow because lawyers add clauses to manage risk from previous projects. Drawing sets grow as tools make sheet production cheap. Coordination processes grow because adding another review step is easier than removing a hand-off that no longer serves a purpose. And then AI is deployed to read contracts that have become too long for humans to parse, thereby freeing up capacity to write longer contracts.
Chesky frames the same insight from a different angle: startups are naturally simple because scarcity forces them. Lack of abundance creates natural constraints, and those constraints are a discipline, not a limitation. Once funding arrives and headcount grows, the muscle for simplicity atrophies and focus diffuses. Assembly OSM’s discipline (no new tool without removing at least one) was an attempt to preserve the constraint mentality inside a funded company. It is almost never practised. The instinct to accumulate is the default; the discipline of removal has to be chosen, actively, against every internal pressure to add.
Dan Heath’s argument in Reset is the discipline version of this: doing less, better concentrating effort on the critical few rather than spreading it across everything, requires a kind of organisational courage that most institutions struggle to sustain. Workflows are political artifacts as much as they are technical ones. Removing a step means someone loses authority over that step.
The self-reinforcing architecture of construction’s complexity
Neil’s twenty-year trajectory is best understood not as a career arc but as a diagnostic. Each move, from design consulting to fabrication to modular construction to general contracting, was an attempt to get closer to the point where the problem could actually be addressed. At each stage, the problem was partly visible and partly obscured by the structure of that particular role. The consultant cannot see the shop floor. The fabricator cannot see the owner’s decision-making. The startup cannot see the procurement dynamics that would determine who pays for what it builds. The general contractor can see everything and must manage all constraints simultaneously.
What the diagnostic reveals is a self-reinforcing architecture: construction accumulates complexity because complexity is where margin hides, where liability is distributed, where scope boundaries are maintained. The tools meant to reduce this complexity get absorbed into it. Better documentation tools produce more documentation. Better coordination tools produce more coordination overhead. The only interventions that escape this cycle are those that remove steps rather than add capabilities to existing ones.
The ERP equivalent for construction, if it ever gets built, will not be the most sophisticated thing in the stack. It will be the most foundational layer, the one that makes structured data flow as a matter of course rather than as a heroic project-specific effort. The fourteen-page shop drawing set for the Berkeley Art Museum was no less rigorous than an eighty-page set. It was more rigorous because it required someone to ask the harder question: what does building this actually require, rather than what can we produce? That question, applied at the industry level, is still waiting for its answer.