Audio article narrated by OpenAI
Lubomir Bourdev’s path is a study in optionality refused. A computer-vision researcher who shipped features inside Photoshop, co-founded Facebook’s AI research lab, and built a video compression startup that Apple paid to absorb, he could have returned to any frontier lab or started another deep-tech company in a field where his reputation preceded him. Instead, he chose construction: the most paper-heavy, change-resistant, liability-driven industry on earth, where his career’s worth of intuition about images and video would mostly fail to transfer. That choice is the interesting part, not the funding or the AI thesis; it reveals something about which problems attract people who have already solved hard ones. What follows is a conversation about why the hardest version of a problem is sometimes the only one worth working on, and what construction demanded that a world-class research career had not.
About Lubomir Bourdev
Lubomir Bourdev is co-founder and CEO of Primepoint, an AI company building a knowledge graph that reads and understands construction drawings. He spent 14 years at Adobe Research, earned a PhD in computer science from UC Berkeley, and was a founding member of Facebook AI Research (FAIR), where he built the image classification engine that processed hundreds of millions of photos per day. He then co-founded and led WaveOne, a learned video compression startup that Apple acquired in March 2023. At Primepoint, he works alongside co-founder Hamid Palo, who carries the consumer-product and UX DNA, and Kamran Azarbal, a former project director at Webcor who joined the leadership team about a year later as the company’s in-house construction expert; the seed round was backed by investors including Navitas Capital and Yann LeCun.
—
“To me construction is another language. I’m actually getting better at speaking it, but construction in German or in Japanese, that’s another ballgame.” Lubomir Bourdev
—
Choosing the hardest problem on purpose
People with Lubomir’s background in software research almost never end up in construction; nothing draws them that way. That was my first question to him: with the freedom to work on anything next, why this?
When Apple acquired WaveOne, large language models were just taking off, and Lubomir read the moment as a rare opening rather than a finish line. He describes it as the best window in a generation to start a company, a period when small startups could become the next Google, and when some of the largest companies today might not exist in a few years. His first instinct was horizontal: wherever a team collaborates on a product, AI could sit in the middle, understanding the actors, the product, and the process. The classroom, an office, a Lego build; anywhere people work together toward something.
Talking his way across industries, he kept arriving at the same place.
“Construction is perhaps the most complicated example of a collaboration, where you have dozens of independent entities with their own schedule and priorities. They basically join forces temporarily to build this sometimes massive project.”
Some projects involve more than 100 subcontractor companies at once. The volume of data is enormous, it changes constantly, and no one can fully stay on top of it. Lubomir finds that appealing rather than overwhelming. He is drawn to tough, high-impact problems, and construction concentrates many of them into a single project. A career spent on face detection, body pose estimation, large-scale recognition, and learned video compression converges on construction drawings: the technical difficulty he has built for, gathered in one place.
This same thinking influenced how the team was formed.
Lubomir came from computer vision and AI infrastructure; Palo came from consumer products and user experience. Kamran Azarbal joined about a year later and has a background in the industry: he started as an engineer, then became a project manager, and later a project director at Webcor, following a full career path in construction. Many AI companies focus on coding, and Lubomir explains why: people who understand AI usually understand software, so they stick to what they know. Construction did not offer him that comfort, so the company’s structure needed to address this challenge from the beginning.
Azarbal functions as an in-house customer and the team’s domain anchor.
“He really went from an engineer to a project manager to a project director, so he knows the pain points inside and out. He can tell us what’s important. What we can evaluate is what’s easy. Obviously the low-hanging fruit are things that are both easy and important.”
The dynamic with Palo runs on productive friction. Palo is impatient, focused on shipping now, no next week, no tomorrow. Lubomir pulls the other way, toward not shortcutting and keeping the big picture intact. He is glad Palo takes the opposite side because the company needs to live in the space between them: move fast while maintaining high quality. The team is not an accident of who was available; it is an explicit answer to the two failure modes that catch AEC startups: weak domain credibility and weak product discipline. Where many founders have to learn construction painfully in the field, the team built the correction into the room.
Why software never moved the needle before
Construction’s reputation as a low IT spender is usually read as conservative. Lubomir reads it as a rational response to tools that never addressed the actual work.
“The reason construction hasn’t spent much in IT is because software did not move the needle for construction. And now for the first time with AI, we’re getting to a point where it can actually help do the work. Before, it was just a way to keep track of the data, and people still had to do the work.”
This is a sharper diagnosis than the familiar “construction is slow to adopt” complaint. The industry was not wrong to underinvest in software that digitised paperwork without removing any of the labour. What changes the calculation is not better software in the old sense; it is a technology that does a portion of the work itself. That distinction reframes the entire question of adoption, because it means the resistance was never irrational. It was waiting for something that earned its place.
The knowledge graph, and why order matters
The historical leap in construction software, the one PlanGrid made, was taking paper drawings and making them digital, searchable, and mobile. Useful but limited, because a PDF is static and linear, while construction is deeply interconnected. Their bet is to rethink how the data is represented rather than how it is accessed.
“When you click on a drawing, you want to know everything about it. Who is responsible, where it is on the schedule, how this drawing looked in the previous revision, are there any RFIs associated with it, how it relates to everything else. We turn this static PDF into an interactive experience.”
The architectural decision underneath that experience is the one worth dwelling on. The approach is to build the knowledge graph first, then expose natural language on top. The reason is that the information in a drawing is distributed: the tags on a sheet refer to things on other sheets and in other documents. Their computer vision detects those tags, determines where they connect, and builds the graph from them, yielding both superior navigation for a person and a superior interface for the model to traverse; feed raw data to a conventional LLM, and it has to be extraordinarily sophisticated to find those connections on the fly. The architecture is the same one that Knowledge Graphs and LLMs in Action identify as reliable: the graph provides explicit, verifiable, updatable structure, and the LLM provides the language interface that makes that structure usable. The deterministic substrate anchors the probabilistic model. It also echoes what Joe Cavanagh described in an earlier conversation about Palantir’s Foundry, where connecting data without destroying its context was the whole point; historically, construction software treated outputs as inputs because that was the only way to get them.
Evidence over answers
Errors are where construction’s risk aversion becomes concrete, and the team has had to be precise in handling them. If an error enters the data, it propagates through the graph unless an inconsistency flags it. The governing principle is human-anchored: if a trained construction engineer can say that this drawing refers to that text, the AI should be able to as well. That benchmark matters because it sets the bar where the tool is useful, not where it merely appears confident.
One product runs a constructability review during pre-construction, flagging where the drawing says one thing and the text describes another; a person then decides whether the discrepancy is minor or worth an RFI. In practice, that is one click, nothing to write, the RFI is ready to go. The practical effect is that the tool does not replace the engineer’s judgement; it gives that judgement something precise to work with rather than something to hunt for.
The trust mechanism that makes any of this usable is evidence, not answers.
“What we find very important is not just getting the answer, but providing evidence for the answer. With off-the-shelf LLMs you get an answer and then have to spend all the time verifying it, because it can hallucinate. We provide references; you click and it shows exactly the drawing or the precise line in the table where it says that.”
That design choice is also what suppresses hallucinations: the model retrieves from the knowledge graph rather than generating from statistical patterns, so the answers are grounded in traceable connections rather than confident extrapolation. The result is the same trust architecture that recurs across the most credible AEC AI products. Maegan Spivey made the point bluntly in an earlier conversation at Document Crunch: when you have been responsible for compliance on a live project, “just trust the AI” is not a sentence you can say. Accuracy is the difference between protection and liability. A clickable reference is not a convenience feature; it is what keeps the verification habit alive.
Lubomir’s framing of trust itself is the most quietly radical part of the conversation. AI is never guaranteed to be correct, but neither are people, and we already trust AI to land planes, drive cars, and support medical diagnoses. The relevant comparison is not perfection but the alternative.
“AI can make mistakes, of course. As long as the probability of a mistake by AI is much lower than by a person, then you are much better off using AI.”
A LLM resembles a working relationship with a person more than any tool that came before it. Every instrument the industry has trusted until now has been deterministic: the same input returns the same output, and a wrong answer means a broken tool. A colleague is not like that. They forget small things, wake up in a different mood, read the same drawing one way on Monday and another on Wednesday, and we work with them regardless, because we know how to question, check, and correct. Seen that way, hallucination is less an engineering defect than the familiar texture of collaborating with something that is not deterministic; the discomfort comes from expecting a tool to behave like a tool, when this one behaves more like a person we have not yet learned to trust.
Rethinking the work, not layering on top
Two fears recur in Lubomir’s customer conversations. The first is that AI will be wrong. The second is subtler: that engineers will lean on AI and stop genuinely understanding their projects. He has seen the second fear come true in software, where people start fixing small bugs with LLMs, then build large features, and lose track of what they have built. In construction, he found the opposite.
“Our interactive navigation makes it actually much faster to learn the data. People are much faster at learning what’s expected in a new project. A new engineer says, this is my scope, tell me what I need to know about this thing, and it can be smart about what they need to pay attention to.”
This is the load-bearing conviction of the whole conversation, and it is the one most aligned with where the industry keeps going wrong. The product integrates with Procore and Autodesk precisely so that people do not have to learn new things or change workflows; the AI comes to where the user already is. But the integration is the surface. Underneath it, the real opportunity lies in rethinking how the work is done, not in layering AI onto a process designed for a different era.
Construction’s instinct is to layer. A new tool arrives, it gets bolted onto a workflow built around paper and sequential handoffs, and the underlying logic never changes. The mundane work, searching for data and crunching reports, will be automated outright. The judgment-heavy work will not be automated but will be supported, with all relevant data conveniently presented to enable faster decision-making. The distinction Lubomir draws, between automating the task and rethinking why the task existed in that form, is the difference between software that compounds and software that stalls. It is a tendency that surfaces across nearly every serious conversation in this space, and it is striking to hear it stated most clearly by someone who arrived in construction from the outside.
Why are technical drawings not natural images
Most of Lubomir’s computer-vision training does not transfer to the drawing context. Natural images present challenges of occlusion, pose variation, cast shadows, and colour. Technical drawings have conventions and symmetry, but those conventions are not uniformly applied, so every dataset is different. The fundamental problem is not primarily visual; it is linguistic.
“We don’t have suitable vocabulary to describe what’s in a technical drawing. If you have to describe a natural picture to a blind person, it’s much easier than describing a technical drawing to a blind person, because we’re just lacking the words.”
His analogy makes the mechanism clear. A language grows a rich vocabulary for whatever its speakers must constantly describe; the often-cited example is the many words for snow in cultures where snow shapes daily life. Drawings never earned that vocabulary, because anyone who needed to explain how two elements connect could simply draw it and point. The words were never necessary, so they were never invented. The consequence is that far less narrative text describes technical drawings than describes the visual world, which means far less training data, one of several reasons general LLMs underperform on them. This is almost word-for-word the observation Luke Reeve made: that natural language exists to describe the world and we have no natural language for a construction drawing; two researchers, arriving independently at the same wall. That two builders working separately hit the identical constraint suggests it is not a quirk of one product but a structural feature of the domain.
Their answer is to use computer vision to break the drawing into elements represented in the graph, so the model sees far more than the raw image. The graph is dynamic, tracking previous revisions and encoding the deltas, and it connects non-text elements to the relevant text through multimodal embeddings. The underlying limit is the one Sean Young described: current models lack reliable spatial understanding of 3D relationships, and the structured layer compensates for what the model can’t do on its own.
The core move is to make drawings codable, turning them from visual artefacts into a structured language of addresses and relationships that a model can traverse deterministically. A door is not a pixel pattern but a node: it has a tag, connects to a room, references a specification, and appears across multiple revisions. Once encoded this way, the model operates on something it can reason about rather than something it must hallucinate around.
The missing layer, and the problem of knowing if it works
Lubomir is disciplined about dependencies. His governing rule is not to start a company that requires someone else to build infrastructure first; the team assumes things as they are and provides the missing layer itself. Beneath the high-level structure of drawings and specs, projects diverge wildly, and what is missing is an ontology of construction concepts, their properties, and their relationships; a uniform data foundation that associates this door with this room across an entire document set.
Asked whether that missing ontology might be derived from IFC, Lubomir pauses. IFC is the right instinct, he says; the existing attempt at a shared language for the relationships between building elements points in the right direction. But IFC was designed for 3D models, not for the flat-plan logic of construction documents, and it does not map cleanly onto what the system needs to encode.
The ontology they are building could be standardised in structure but hybrid in ownership. The core relationships, how a door tag points to a room, how a tag links to a specification, and how elements cross-reference across sheets, are the parts Lubomir is open to releasing publicly, so every firm could build on the same substrate and the industry would gain network effects from a shared language. The proprietary part would be the extraction engine, the local rule sets, the firm-specific abbreviation dictionaries, and the performance optimisations. The structure is open; the implementations are competing. He frames this as a possibility rather than a settled commitment, which is what makes the next question the real one: should the foundation be open source?
“I definitely believe open source is the way to do it, because we want to leverage everybody to build on top of it. If you are hiding everything, then you cannot move as fast as if you open source and have others build on top.”
The instinct points at the same structural truth others in the field have circled: whoever defines the shared data language shapes how the next generation of building gets built. A foundation owned by everyone moves faster than one hoarded by a single company, but the team that built it first owns the deepest understanding of what the language can express, and that understanding is the durable moat.
Evaluation, though, is where his honesty is most useful. In computer vision, you collect tens of thousands of labelled examples, split them into train and test, and measure which method wins. Construction breaks that method.
“Every construction project is different. To have a statistically significant set you cannot use one or two datasets; you need several hundred at least. But where are you going to find all these datasets and then label them? Otherwise it’s easy to overfit. I don’t have a solution here.”
This is rare candour from a founder. The data and ontology Lubomir is describing are construction drawings themselves: the sheets, tags, specifications, and cross-references that together define what gets built and how. Each project generates thousands of pages of this material, each with its own conventions and abbreviations, and no standard labelling scheme covers them all. The thing that makes that data hard to model is exactly what makes it hard to evaluate: uniqueness across projects means there is no agreed-upon ground truth at scale. Open benchmarks for drawing understanding are only beginning to appear, and the few that exist split along a revealing line. AECV-Bench probes whether a model can even read a single drawing: OCR, counting and spatial reasoning over one sheet. AEC-Bench goes further, testing agents on cross-sheet and project-level reasoning over real drawing sets, which is the harder problem Lubomir is describing. Both are among the first to measure this directly, though no single benchmark yet covers the diversity of real projects. AEC-Bench’s headline finding is telling: retrieval, not reasoning, is where agents fail most, because they cannot reliably locate the relevant sheet or detail in the first place. That is precisely the gap a knowledge graph is built to close. The open-source ontology and the evaluation problem are, ultimately, the same problem viewed from two sides.
This is the part of the conversation the industry isn’t having enough of. Lubomir’s candour is rare, but the gap is wider than at Primepoint: evaluation is treated as an afterthought because the field’s understanding of the technology is still immature. No one can claim reliability at scale without a benchmark, and no fair one yet exists. That cannot stay a problem for later; it belongs at the centre of how every vendor in this category talks about its product, because without it, “trust us” is the entire pitch.
Localisation and the risk of a shared blind spot
The final frontier is geography. Drawings are semi-universal; an elevation is an elevation, but language and explanation are not. Moving to another country is not merely a matter of different codes and conventions; it is that debugging becomes nearly impossible when you cannot read the language in which something went wrong. Vertical and linear construction differ, too, in the nature of the data itself. Vertical stacking of many disciplines (architectural, mechanical, plumbing) in the same area, with dense interconnections and overlapping scopes, creates more room for error. Linear work, the highways and tunnels and bridges, is more sectional, organised by station from here to there, with different kinds of tags. More startups are chasing vertical, Lubomir notes, not necessarily because it is harder, but because the problems are simply different; the team is beginning to expand into linear as well.
There is a quieter risk embedded in the localisation question, one that AEC Magazine has flagged in its writing on agentic BIM: if the industry converges on a small number of shared foundation models, all trained on similar data, it risks what researchers call cognitive monocultures. A systematic misreading of, say, fire egress requirements would then not fail on one platform but across all of them at once, and a code error that should fail locally would propagate everywhere the model is relied upon. Lubomir’s insistence that codes, regulations, and language differ country to country is, read this way, an argument against a single universal model and in favour of structured layers that can encode local differences. The blind spots of a shared brain are blind spots in common.
What surprised him most was not a specific technical challenge, but how closely everything in construction connects across fields and levels. His background helps him less with details and more with the way to approach problems: how to tackle hard issues, what to measure, and why things matter. He keeps returning to a key idea: when his company expands internationally, language barriers make it hard to tell if something has gone wrong. “To me, construction is another language. I’m actually getting better at speaking it.” This viewpoint is more about diagnosing issues than longing for ease; it shows a willingness to learn from difficulties rather than resist them.
When the substrate decides what the model can be trusted to do
Read the threads of this conversation together and they close into a single loop. In the immediate future, general-purpose AI cannot operate reliably on construction’s distributed, multimodal, jurisdiction-specific data without a structured layer that encodes the domain’s relationships, vocabulary, and rules. Build that layer first and three things follow at once that look unrelated but are not. Hallucinations are suppressed because a deterministic graph anchors the probabilistic model. Trust becomes reachable because every answer can carry a traceable citation rather than a confident fabrication. And localisation becomes a design parameter rather than a wall, because differences can be encoded in the structure rather than baked into a model’s weights.
There is a signal in how Primepoint’s customers are beginning to respond. General contractors who would have spent another year evaluating are choosing to act now, not because the technology is perfect but because they recognise the asymmetry: the cost of moving on imperfect AI is manageable; the cost of waiting while the technology compounds is not. The imperfection is known and visible; the risk of standing still is structural and silent.
The same architecture that makes the answers reliable is the one that makes them verifiable, lets the system travel, and resists the cognitive monoculture; not three features but one decision viewed from three angles. The reason a researcher who built internet-scale recognition systems is the right person to make that decision is that he arrived without the construction instinct to layer. He could see that the industry never underinvested in software out of stubbornness; it underinvested because the software only ever tracked the work instead of doing it. What changes now is not that construction has finally become willing to adopt. It is that, for the first time, there is something underneath the adoption worth trusting.