Audio article narrated by OpenAI
At Sound Transit, the chief engineer who opens a station is not making an efficiency decision. He is making a safety decision that will hold while hundreds of thousands of commuters pass through that station biweekly, across 4,500 as-built drawing sheets that no team can humanly review in full. The question TwinKnowledge set out to answer is not how to automate that review; it is how to give the engineer and their team agency over making more confident decisions. Luke Reeve, Head of AI Solutions, is the person closest to that question. He left structural engineering after two weeks reviewing fabricator drawings against design intent, six hours a day, on a steel build in Atlanta long enough to understand, from the inside, what the industry was asking of its people, and what it was costing them. What follows is a conversation about what it means to build AI-native products in an industry that has spent decades layering complexity onto problems it never quite solved.
About Luke Reeve
Luke Reeve is Head of AI Solutions at TwinKnowledge, an AI-native construction document intelligence company serving enterprise clients including Sound Transit, Toll Brothers, and the Port Authority of NY/NJ. Trained as a structural engineer at Georgia Tech and as a design researcher at Harvard GSD, Luke joined TwinKnowledge at its earliest stage, working alongside founder Ivan Panushev to build what they describe as a knowledge layer for the built environment. His role sits at the intersection of applied AI research and client-facing solution design, making him the person closest to both the technical architecture and the product’s field-deployment reality.
—
“When you can tap into someone’s ability to find meaning in what they do, that’s when you start having real effect in people’s lives.” Luke Reeve
—
Three conditions for AI that engineers will trust
The Sound Transit case is TwinKnowledge’s most cited proof point: 1,300 percent improvement in review efficiency across 4,500 as-built drawing sheets reviewed biweekly. The number is striking. But Luke is clear that the number is not the point.
“We’re helping to give the chief engineer more confidence to open stations, not just improve review coverage — which is part of what we do, but that’s not the end goal. The end goal is to give him more confidence. When you can tap into someone’s ability to find meaning in what they do — for him, he’s keeping the entire Seattle region safe — that’s meaning. That’s when you start having real effect in people’s lives.”
The distinction matters for product design. Optimising for review coverage produces a different product experience than optimising for decision confidence. Coverage is a throughput metric; confidence is a trust architecture problem. To get an engineer whose professional liability rests on a safety decision to rely on an AI system, three conditions must be met simultaneously.
Luke names them with the directness of someone who has tested each against real clients:
Transparency: every answer must carry a clickable reference to the source document, surfacing the exact passage that grounded the AI’s output. Not a sheet number; a linked view of the highlighted text. The friction of a non-linked reference is enough to break the verification habit.
Bite-sized delivery: KPF Architects reframed TwinKnowledge’s original workflow model entirely. The instinct was to run large checks at milestone stages: 30 percent CDs, 60 percent CDs, 90 percent. KPF pushed back. They wanted a daily product, not a milestone product. Check the doors on this floor for ADA compliance today. Twenty items, 50 items; something a reviewer can actually interview and close.
Controllability: When the AI produces a result the user knows is wrong, what can they do next? This is where generic AI tools fail in production environments. With a closed model, you get what you get, and the path to correction is opaque.
“With building a layer on top of the models, we have all these levers we can use — fine-tune, even build new tools — to help them get to the answer they want. With Copilot or ChatGPT, when you don’t get what you want or it’s incorrect, what are your steps? They just aren’t there, especially for our data in our industry.”
Clifton Harness of TestFit, speaking on the Bricks and Bytes episode on 80/20 advice for construction AI, put the challenge bluntly: a lot of AI tools sold to construction companies right now deliver 80 percent of the value of opening ChatGPT, in one percent of the time, with none of the integration. The implicit question is what the remaining 20 percent actually requires. Luke’s three conditions are a direct answer: transparency, granularity, and correction pathways are not achievable by pointing a generic model at a messy drawing set. They require a knowledge layer built specifically for how construction documents behave.
Born in AI: why the architecture matters more than the model
One of the cleaner ways to understand TwinKnowledge’s competitive positioning is to ask why incumbents cannot simply replicate it. The answer Luke gives is not about data access or distribution; it is about organisational architecture.
“A lot of issues we see is companies trying to shoehorn a traditional product into an AI product. You’re missing the point. It’s got to be the foundation. That’s where you can have this platform layer, this knowledge layer, this data layer, that you can then just apply all over. Legacy mindsets — not just legacy code bases, but legacy mindsets — into an age of AI product? That’s going to be very difficult.”
The distinction Luke draws between “born in AI” and AI-as-feature echoes a framework Sangeet Paul Choudary develops in Reshuffle: the AI-native firm is not one that has added AI to existing workflows, but one in which every process is designed with feedback loops that make the organisation itself learnable. The knowledge layer is not a bolt-on; it is the load-bearing structure. Everything else connects to it.
The legacy mindset is not abstract; it has a specific operational signature. Cat Wu, Anthropic’s head of product, captures the dynamic in How Anthropic’s product team moves faster than anyone else on Lenny’s Podcast: feature timelines that once ran to six months now compress to a week. The organisations that adapt are the ones that treat shipping as a learning mechanism, not a delivery milestone. The engineering perfectionist who cannot make that shift not only slows down, but they also optimise in the wrong direction. A perfect feature built on an incorrect assumption is worse than an imperfect feature that reveals the assumption is wrong. That reframe is not a stylistic preference; it is the precondition for a product designed to learn from every use.
This has specific technical implications for construction documents. As Lubo from PrimePoint explained on the Bricks and Bytes episode on AI, not buying into the advantage: LLMs are trained on natural language, and natural language exists to describe the world. We don’t have natural language to describe a construction drawing. The tags on one drawing reference tags on another drawing, which reference a specification, which references a schedule. No single drawing contains the answer. The model on its own is useless. What matters is the connected data around the model.
The knowledge layer is precisely that connected data: the tooling that teaches the model what drawing language means, how chunks of visual information relate to each other, and how to maintain consistency across a document set that was never designed for machine readability.
“Drawing sets are a new language for machine learning, for AI. And we’re giving it tools, along with training, to understand this language. There’s so much connectivity — specifications and plan views, plan views and sections and details. It’s a big network, like a graph. We’re building the tools that help our models understand this language, and we’re relying on reasoning ability to keep improving.”
The platform and workflow distinction, explored in a previous conversation about staying focused in fragmented markets, surfaces here as a live architectural choice: the engine stays constant, while how intelligence is deployed across different project areas and client contexts flexes. Toll Brothers uses it for land assessment, financial data and drawings. Sound Transit uses it for safety-critical as-built review. The knowledge layer is the same; the workflows are shaped to the use case.
This distinction has a specific operational consequence. The team does not build custom versions of the platform for individual clients. The workflows are consistent; only the context in which they run differs. Luke describes it as a single underlying engine that powers all workflows: given that the platform understands construction documents, the question is always how to deploy that understanding to a specific project area. The answer changes; the engine does not. Every improvement to the platform, every new tool added to the knowledge layer, propagates simultaneously across all client deployments. Sound Transit and Toll Brothers are not running different products; they are running the same product against different data and different use cases. In an industry where enterprise software typically fragments into a patchwork of bespoke configurations that require separate maintenance, this is a meaningful structural advantage: one engine, maintained once, compounding across an entire client portfolio.
The compounding dynamic is what makes this more than a feature claim. As more project data flows through the system and more client-specific vocabulary and drawing conventions are trained into the model, the gap between the platform’s outputs and a generic AI’s widens. Martin Fischer of Stanford, on the Bricks and Bytes episode on 80/20 advice for construction AI, framed it clearly: the right bet is not training AI on the digital exhaust of an industry about to change shape; it is building new digital workflows that produce useful data as a byproduct of the work itself. The review workflows are exactly that: each review cycle produces structured, project-specific feedback that the knowledge layer learns from.
The 2D/3D question and the simplicity imperative
The future of construction documents is a question that tends to produce confident predictions from people who have not spent time with a full-size plan set. Luke’s answer is grounded in a more specific framework: cognitive load theory and the phenomenology of detailed design.
“When you get down to a plan, a PDF, and you’re doing design on a PDF and not a 3D model, there are things you think through that you don’t think through in the model. When you’re trying to get into a detailed design of something — window flashing, waterproofing — you need to simplify your view. There’s so much detail that goes into one section. And that’s where PDF drawing sets will always have the advantage.”
The argument is not nostalgic; it is architectural. Three-dimensional models carry the full complexity of a building simultaneously. A section detail on a sheet forces a deliberate narrowing of focus. That narrowing is not a limitation of the medium; it is the cognitive mechanism that enables detailed design. The brain, as Luke notes with some understatement, processes only so much complexity at once in a single view.
The resulting vision is not a binary shift from 2D to 3D, but a data-layer synthesis in which both modes speak to each other in real time. Detail a waterproofing layer as a line in a 2D window section; the model treats it as a wrap condition and renders it in 3D. The 2D informs the 3D, and the 3D context prevents the 2D designer from missing a corner condition they can’t see from a single viewpoint.
“Imagine detailing in 2D, and that shows up in 3D because the understanding is there. It’s a data layer. Going from 2D to 3D versus 3D to 2D, and that both-way communication — I think that kind of symbiosis is the future.”
Against this backdrop, Luke’s closing argument for simplification lands differently than the standard critique of AEC’s technology stack. The industry has layered software on software without closing any of the feedback loops that would make each layer accountable to the one below it. Joseph Tainter’s analysis of complexity and declining returns in The Collapse of Complex Societies describes the same mechanism at the civilisational scale: each additional layer of specialisation yields less return than the one before it, until simplification becomes structurally more valuable than further elaboration.
“We need to simplify. We have so much technological bloat in our industry. So many software layers without solving the base problems. I want the industry to go back more towards the practice itself, the craft. Think of Gaudí: gorgeous models, very simple but elegant studies. He was intimate with how things worked at a small scale and how that scaled up. Involved in the physics of it, the feel of it, how it structurally went together.”
This is not an argument against technology; it is an argument for technology that reduces cognitive overhead rather than adding to it. AI, deployed as a translator between fragmented information and human decision-makers rather than as another application layer, is the mechanism that enables the simplification. The drawing set serves as input, the structured, relational knowledge layer as output, and the engineer returns to the part of the work that drew them to engineering in the first place.
Empathy as a technical specification
The simplification argument is not abstract for Luke. It is the residue of a specific professional experience, grounded in specific workflows at specific stages of a project. When he describes why he left engineering, the language is precise: it was not disillusionment with the field, it was a specific experience of a specific kind of work. Two weeks. Six hours a day. A fabricator drawing set and a structural design set, side by side, checking every column connection.
“I experienced that. It was painful, and it was tough knowing that I’d done undergrad, grad. It kind of took the love for engineering out of the work for me. And so I have that empathy and that respect for what people do, because I know. I didn’t want to do it anymore.”
In a previous conversation about finding AEC pain worth paying for, the argument is made that the strongest AEC products begin with pain the builder has personally experienced. The knowledge is not just intellectual; it is somatic. You recognise the problem because you still remember sitting with it. Luke’s two-week drawing review is that moment: the origin story that functions as a technical specification for the product he is now building.
That specification allows Luke to describe what a project manager is not saying in a client meeting because he understands the PM’s incentive structure. He can identify that the engineer in a discovery call is worried not just about accuracy but about accountability, because he was once that engineer. The training in engineering rigour is not discarded in a startup; it is repurposed. The instinct toward completeness, transposed from a single deliverable to a knowledge layer, becomes the discipline that makes a trust-architecture product possible.
It is also the instinct an early-stage team has to manage, not indulge. In construction, the pull toward completeness is not irrational: a missed connection, a wrong-sized member, a skipped detail can have physical consequences. Breaking that pull at the product level requires reframing what “good” means at an early stage.
“In engineering and school, you’re trying to get to a perfect solution in an ideal environment. But that’s the opposite of a startup. You can still be sitting there thinking: we got the 80%, we should really sit here and refine and make sure we have it perfected. And you can’t. Information changes so quickly. You talk to another big client the next week and realise an assumption was entirely wrong.”
The reframe, as Luke articulates it, is that learning compounds in ways that correctness does not. Design theory, he notes, is sound in principle; the question is how much of it survives contact with the constraint of a current client deliverable. The answer, in practice, is: less than you’d like, and more than you’d expect.
“Learning is your greatest currency early in a startup. It’s about how fast you can move from an assumption to a closer reality.”
This empathy extends into the sales motion. When the team works with a champion user at a client firm, Luke describes the process not as persuasion but as translation. The story the power user tells is not the story the budget holder needs to hear; the product team’s job is to carry that story upward through the organisational hierarchy, letting each level reinterpret it in the language of their own incentives. This dynamic, explored in depth in a conversation about the stories that shape products, is one of the more consistent patterns across AEC product conversations: the product itself is rarely the hardest thing to sell; the organisational navigation is.
What compounds when the model learns
The underlying structural argument is that the knowledge layer becomes more valuable over time, not less. Each project adds vocabulary. Each review cycle adds relational data. Each client engagement narrows the gap between what the model understands about construction documents and what a senior engineer instinctively understands.
This is the “born in AI” claim operationalised: not just that the product uses AI, but that the product is designed to improve through use. Luke describes the human-computer interaction challenge this creates: how do you communicate to a user that the product they are using today is not the product they will be using in three months, without requiring them to relearn it every quarter? The product must surface its own improvement in ways the user can recognise and trust.
The incumbents cannot replicate this, not because they lack the model capability, but because they lack the organisational architecture that makes continuous learning the default state. A legacy product with AI features added does not produce feedback loops; it produces features. The loop is only possible if learning is foundational to the system, not instrumental to a roadmap decision. Diana Hu’s framing from the Y Combinator Startup Podcast captures this precisely: to build closed loops, the entire company must be queryable. Every action must produce an artefact that the intelligence layer can learn from. The architecture is built around exactly that principle.
Once embedded in a client’s project portfolio, the knowledge layer becomes the data infrastructure for every subsequent workflow. Cross-project aggregate intelligence, lessons learned at scale, process changes that compound across 20 projects rather than one: these are not product features so much as architectural consequences of getting the foundation right.
The weight behind the decision
At Sound Transit, the chief engineer who opens a station is not making an efficiency decision. He is making a safety decision that will hold while hundreds of thousands of commuters pass through that station. The AI system’s job is not to make that decision for him; it is to give him the confidence to make it well.
That framing encapsulates the entire product philosophy in a concise form. Transparency so he can verify. Bite-sized delivery so the review is manageable before the decision point. Controllability so that when the AI’s output surprises him, he has a path to resolution that does not require abandoning the tool entirely.
The product is not a replacement for the engineer’s judgment; it is the infrastructure that makes judgment possible at the pace the project demands. The knowledge layer underneath it accumulates over time, project by project, client by client, review cycle by review cycle. The model that understands one firm’s drawing conventions becomes the model that understands the recurring failure modes in their specification language; it becomes the model that surfaces risk patterns across a portfolio before any single project review would catch them.
This is what “born in AI” means as a product strategy rather than a marketing claim: not that AI is present in the product, but that the product is designed to compound. Every use makes the next use better. Each review adds to the relational graph, making the next review faster and more confident. The knowledge layer is not a feature; it is the mechanism that converts project data into institutional intelligence. And institutional intelligence, in an industry that loses it every time a senior engineer changes firms, is exactly the thing worth building.