AI, Engineering, and the Messy Physical World
By Atif Z. Qadir, AIA - October 2026
I am an MIT alum, trained as an architect, who went back to school for computer engineering and moved into AI. After about 20 years in the built environment and about five months seeing how frontier models are trained on engineering work, here’s what I discovered and where I believe physical engineering is going.
What I’ve done
I am a licensed architect. I’ve worked in design and construction for large firms in New York, before taking an entrepreneurial path. I developed real estate myself and started a technology company focused on the industry. Those experiences drove my interest in how AI would affect this work. That led me to graduate studies in computer engineering, and most recently, to Handshake AI. In my first days at the company, I visited a frontier lab in Brooklyn. Once there, I heard clearly that they needed training data that was contextual to a professional domain and reflective of the work experts produce.
At the company, I worked on frontier-model training and evaluation for professional engineering workflows. I started by turning work that architects and engineers actually perform into what the human-data world calls “tasks.” They consist of model prompts, source materials, expert-verified golden answers, and evaluation rubrics. I did this work alongside other domain experts and frontier AI lab customers. What became interesting to me was not simply whether models could perform these tasks, but where they failed. From there, I looked for what those failures had in common and what that might tell us about building useful AI for the physical world.
I use the term “physical engineering” broadly to describe workflows involving the design and production of physical systems. These require diverse skills: observing, interpreting, reasoning, pattern-finding, and deciding with incomplete information. They result in visual artifacts that guide work in the field. Physical engineering includes the built environment - architecture, civil and structural engineering, and related fields. My direct experience is deepest there, so that is the source of my examples here. I suspect that some of the dynamics extend to other physical engineering fields but that is for practitioners in those fields to comment on.
What I discovered about physical engineering
The physical world is messy - some of it is noise and some is signal
The process of design is iterative with frequent loops backward as new information changes earlier decisions. Physical engineering industries contain redundancy and repetition because the underlying world they operate in is heterogeneous and, well, made by different people. There are messy documents. For example, a drawing set I used showed the building elevation in different ways with contradictory numbers. There are messy workflows, with mind-numbing back and forth. Consider a code compliance review I modeled that would have involved at least three professionals in the real world, each likely with their own interpretation of overlapping and conflicting jurisdictional building codes. There are messy contexts where the goals aren’t shared across parties. In one task, I modeled general construction bidding where one of the bidders did not want the job and had inflated the numbers to accomplish that. That is a real world scenario. Together, these create a multilevel “messiness taxonomy” for models to navigate. So what is noise versus signal in the mess? In my experiments, models were not thrown off much by low-resolution images, coffee-stained scans, or even vast document libraries. What affected model performance more were messy workflows and contexts - multiple versions of construction documents and overlapping building codes.
Down the block from my home is a historic townhouse I admire. Recently, I used the construction drawing set for the building to write tasks. When I tested an Anthropic frontier model on the tasks, it found apparent errors within the drawing set. Some errors were real but immaterial. Others did not exist at all. Meanwhile, the building was built. It got a certificate of occupancy. People lived there. These are cases where you need professional judgment to know the difference and understand the consequence. The opportunity for AI then is not simply to force physical industries into cleaner workflows but to build machines capable of reasoning within ambiguity across multiple modalities.
Judgment becomes the bottleneck as capability grows
When I think of good judgment in the built environment, I think of the owner of Extell, the company where I learned how to acquire and develop real estate. When I presented a project to the owner for review, he was faster with mental math than I was using a calculator. I quickly realized it was a reflection of his ability to find the relevant variables in a mess of numbers and identify what they meant relative to the goal at hand. I think professional judgment isn’t knowing everything; it is determining what information matters, finding patterns in it, and deciding what action should follow. I built a task around a rooming house in the College Hill section of Providence. I told the frontier model that my goal was to convert the building into high-end, traditional apartments given the improving real estate market around Brown. I gave the model everything I would have used as a real estate professional. It failed in the ways a really bad development associate would - it didn’t look at the codes and made stuff up when I complimented its expertise in a niche part of project planning. And the stuff it made up sounded convincing. It also drew on top of the drawing set I had given it but applied the wrong codes in doing so. Finally, it produced impressive-looking work without actually solving the problem. I eventually found it useful to frame professional tasks around a decision rather than just a visual artifact. A calculation, for example, is evidence but the economically valuable output is the decision that industry professionals would make from it.
As an experienced architect, I navigated ambiguity in construction drawing sets. In response, I would issue an Architect’s Supplemental Instruction (ASI). That’s not just information retrieval. It is identifying the context and picking the action that should follow. There are limits to this, as I realized when reviewing electrical drawings against the applicable codes for a frontier model task. I made mistakes and was reminded that general domain knowledge doesn’t equate to task-specific knowledge, even if that task is adjacent to my area of expertise. In contrast, a technical architect with years of code compliance experience who worked with me on a training pipeline, Michael, found many relevant issues the frontier models did not and reliably graded the importance of his findings. In other words, “Get paan from the paan maker. Not the chaiwala.”
So, given the right tools and context, a frontier model may be capable of performing parts of a professional workflow. But good judgment from a model requires much more. It requires saying no to answers that merely look plausible. In doing that, a model doesn’t work alone. The harness around it determines what information it can access, how it moves through a task, and how it responds as new information arrives. In my testing, some of the failure modes persisted across models and harnesses, suggesting limitations in the underlying capability. But the harness could also change the behavior itself. When I introduced incorrect pushback (as happens in the field amongst professionals adamant about their perspectives) into a task, models sometimes abandoned correct reasoning or returned less work than they had actually done. So, the judgment we observe isn’t simply a property of the model. It emerges from the interaction between the model and the harness. Determining how well the joint system exercises judgment depends on how we evaluate its outputs. As in the real world, that evaluation should incorporate multiple professional perspectives to isolate actual error. Taken together, these experiments suggest that technical knowledge matters, but so does finding and using the relevant information distributed across documents, construction sites, and team members.
The scale of work modeled in a task has to retain context
Recently, I spoke with a senior executive at a national homebuilding company about what his teams do and the data they produce in the process. A team there retrofits construction drawing sets for one region of the country to be used in another region. Inspired by that, I designed a frontier model task to evaluate a set for a single-family home development in Columbus, Ohio and compare it to the codes that are applicable in Westchester, New York. The goal was to identify what would need to change to make the design buildable there. The task as I defined it was too broad for frontier models. They could not provide expert-level comments on the details that needed to change, let alone consistently reference code sections that actually existed. The model failures I saw clustered around completeness of the work and accuracy of what was produced. The underlying triggers often were poor navigation across dense documents, poor domain comprehension, and missed conditional decisions and constraints. There are large use cases like this across the industry, especially where scale allows you to drive topline revenue on tasks where pattern finding may be intertwined with judgment, like this one.
At the other end, how far can professional workflows be decomposed into small tasks? In experimenting, I found frontier models were already good at the bounded task of counting objects. These tasks are separable from judgment but not economically consequential on their own. So, tasks can fail in both directions. Too large, and models lose reliability across the workflow. Too small, and models can’t drive the economic value that is the point of using AI in the first place. The challenge is finding the right unit of consequential professional work, and building environments that are capable of supporting the messy process around it. Tying these two examples together then: Counting doors? Trivial pattern finding. Checking a door against dimensional requirements? Multimodal navigation and comprehension. Producing a sketch that shows that moving the door solves accessibility but screws up structure, circulation, or furniture planning? Applying technical knowledge and tools. Determining whether the door should move? Judgment. Seeing this spectrum makes it clear that “count the doors” and “design me a building” are two unhelpful extremes. Between them is an enormous consequential middle: workflows that remain bounded enough to train and evaluate models while being valuable.
Where I believe physical engineering could go from here
Build an engineer-in-training, not an engineer
Physical engineering is an interesting place to test generalized intelligence because it crosses the virtual and physical worlds across modalities. A building isn’t just a PDF drawing set. It exists simultaneously as code analyses, schedules, permit applications, renderings, and then physical matter. A professional needs to jump between them. In response to this difficulty, the industry has prized ultraspecialization because developing good judgment has been so time-consuming. Looking forward to hybrid computer-human systems, the first hurdle will be making long-running, multimodal workflows less expensive with a model helping than with a human alone. The second will be performing the workflows with consistent quality. That becomes harder as models encounter the long tail of context-dependent conditions common in physical engineering. For clarity, I am working from the assumption that our shared goal is to liberate engineers from work that is largely about pattern finding and allow them to focus on work that is grounded in judgment. For now, that suggests not trying to replace the human engineer but building something closer to a virtual engineer-in-training: capable of meaningful work, but still accumulating context and requiring review because it is not ready to own consequential decisions. Some companies are already pushing in this direction, designing models to work within human-led teams and use the same tools as human engineers. With this immense possibility, it is critical then to ask what physical engineering in the future, in any form, could and should be.
Train for incremental decision-making and consequences, not just artifacts
Human-data pipelines often linearize professional workflows that aren’t linear. That structure can be useful but it can flatten the messiness of physical engineering. The visual artifacts professionals produce are usually snapshots of a longer process. Interactive training environments, including those used for reinforcement learning where models learn through feedback on their actions, offer one way to preserve more of the signals from the messiness taxonomy. Useful environments may need to be multi-turn (incorporating project history and consequences) and recognize ranges of professionally acceptable decisions rather than assuming every problem has one correct answer. They will also need rubrics that evaluate the incremental decision-making, not just a plausible final answer. All this will require repeated trial and error. The goal isn’t to reproduce the real world, but it is to preserve enough of it so an answer is professionally useful. There is also no reason to assume that the end state should reproduce today’s engineering workflows exactly. Those workflows evolved around human limitations and sufficiently capable machines may allow us to change the workflows themselves. Over time, frontier models will move from completing bounded tasks to drafting, recommending, orchestrating, acting with review, and perhaps eventually acting alone. Each of these stages raises the cost of getting a decision wrong along the way. That means capability will not be the only frontier. As models take on more consequential work, questions of verification and liability will become increasingly important. Getting a model to complete a structural load calculation accurately is different from trusting it with multi-step decisions that could endanger human lives.
Rethink apprenticeship as junior work disappears
The judgment that Michael, the domain expert I mentioned earlier, exhibited didn’t suddenly materialize when he received his professional license. That kind of judgment accumulates through lower-level tasks - observing senior people, trying things out, getting corrected, and seeing the consequences. If junior work is where people build this, automating that work will remove the very mechanism that produces Michaels. And Michael isn’t just expensive training data for frontier models. He is the thing the physical engineering industries have to continue preparing. A new version of apprenticeship and licensure should recognize this. Maybe frontier models will become tutors, giving apprentice engineers a platform for repetition and mastery of fundamental concepts. They could let apprentices encounter hard problems earlier in their careers in low-stakes virtual environments. Perhaps private models will be trained on the communications of technical partners, allowing their knowledge to be available to junior staff, as a major engineering firm recently did. Maybe the licensure exams themselves will be virtual environments modeled on real world systems. That could replace multiple choice questions and case studies, which are just static impressions. There is also another future to consider. Cheaper engineering may increase the amount of engineering we do, and the number of human engineers we need. If frontier models dramatically lower the cost of engineering, hybrid human-computer teams could offer solutions that are currently impractical or impossible. We could increase the scale of execution, rather than just doing the same engineering for less money.
What remains unresolved
Frontier models sometimes feel unnervingly human. While checking the quality of a complex set of engineering tasks, Fable 5 asked me what the arrows meant in a section cut. Just before, the model had been able to make impressive-looking, albeit wrong, structural calculations. It then endearingly asked this question I would have expected from an intern. For a professional in the field, the answer is obvious: the arrows denote the direction to look when making the cut, providing the visual context for the tagged section detail. Frontier models may eventually become extraordinarily good at finding everything wrong with a drawing. But useful intelligence in physical engineering requires something harder: exercising judgment within real world messiness.