Audio article narrated by OpenAI
Emile spent years as a hands-on developer before moving into software architecture and then into product management at Autodesk, where he led the Revit software architecture team and its verticals. Two decades of not writing a single line of production code. Then AI made it possible again: not just easier, but genuinely feasible. In this conversation, we explored what it means to build in 2026: why the window is real, why experience still matters more than ever, and what AEC teams risk if they wait too long to paddle.
—
About Emile
Emile Kfouri is a former product leader at Autodesk, where he led the software architecture team for Revit and its vertical products. A structural engineer by training (Northwestern University, 1991) who began coding at 14, he traced a career from roughly 20 years of hands-on software development to chief architect and various product management leadership roles: a trajectory that gave him rare fluency across both the technical and strategic dimensions of building software. He is now coding again, for the first time in two decades, using AI as a creative collaborator. His perspective sits at the intersection of deep software craft and the practical realities of building for the AEC industry.
—
“I’m writing code without seeing a single line. I describe the intent. The AI creates the implementation. And I still have the creative satisfaction — without the debugging frustration.” Emile Kfouri
—
There’s a particular kind of statement that signals something real is happening in a field. Not a prediction, not a claim from a vendor, but a practitioner describing their own experience in a way that makes you stop and recalibrate. Emile’s return to coding after 20 years away is that kind of statement.
He didn’t go back to writing code because he had to. He went back because, for the first time in two decades, the friction was low enough that the creative part could dominate. That shift matters: Emile isn’t using AI to go faster at work he was already doing; he’s using it to do work he had stopped doing entirely. That’s a different category of change. And it points to something broader that AEC builders and product teams need to take seriously: the barrier to building has dropped in ways that change who gets to build, what they can build, and how fast they can move.
Three dynamics make this moment structurally different from previous technology transitions in AEC: the rebundling of expertise and execution that AI enables; the experience premium that determines how well those tools perform; and the process lag that turns development speed into organisational friction unless the surrounding structures adapt. They are interconnected. The rest of this conversation is about how.
The rebundling moment
Emile’s career traced a trajectory many senior technical people will recognise: developer, then architect, then product manager. Each transition traded hands-on creation for coordination, strategy, and oversight. The code became someone else’s responsibility.
That separation made sense when software development was the long pole in the tent. When building a feature took weeks and required specialist execution, it wasn’t feasible for a product leader to stay closely involved in the implementation. The roles separated by necessity.
AI has begun to dissolve that necessity. As Sangeet Paul Choudary argues in Reshuffle, the entrepreneurial advantage now comes from turning unique skills into reusable building blocks: “Rebundling,” he calls it, the reassembly of tasks and components into new roles and workflows driven by new constraints. Emile’s two decades of debugging knowledge, systems architecture instincts, and product thinking didn’t become obsolete. They became the raw material for something new. The AI does the implementation. The experience does the directing.
The fear that AI will take jobs misses the more interesting dynamic. What AI is doing, at least for people with genuine depth, is collapsing the distance between “I have an idea” and “the thing exists.” That’s not a threat to experienced practitioners; it’s an accelerant.
Experience is the moat
That accelerant comes with a significant caveat, and Emile was direct about it.
“AI-led coding relies on years of debugging and architecture knowledge. The industry must provide learning opportunities for less experienced developers.”
This matters because the optimism about AI-enabled building carries a real risk: the assumption that the tool itself is sufficient. It isn’t. What makes the human-AI combination powerful is the human half. The ability to spot what’s missing in a generated output, to know when an architectural decision will create problems three steps later, to sense when a solution is technically correct but practically wrong: these capacities come from experience, not from prompt engineering.
Emile’s chess analogy captures the mechanism precisely. The most interesting games right now aren’t human vs. AI, or AI vs. AI. They’re human plus AI versus human plus AI. The human adds a critical 10 percent that, in Emile’s estimate, saves thousands in model costs: one good review by someone who knows what to look for outperforms expensive iterative AI testing by a wide margin.
For AEC teams thinking about how to use these tools, this is a structural insight. The question isn’t whether to use AI. It’s whether you have the experienced people who can direct it well. Young developers need mentorship not as a courtesy, but as a prerequisite for AI-assisted work to produce reliable results. The depth of your team’s experience determines the quality of your AI’s output. Stripping out senior practitioners in favour of cheaper, AI-assisted junior work doesn’t reduce the need for expertise; it just hides the deficit until something breaks.
What adequate experience looks like in practice is something Emile is direct about: onboarding. “You would never hire an employee, point them at the most difficult programming task on your codebase, have them fail, and then say it’s their fault.” The same logic applies to agents. The teams that perform best aren’t the ones that pointed the model at the hardest problem and waited. They’re the ones that treated agent deployment like a new hire: gradual introduction, clear scope, calibration over time. Dan Shipper, who builds production AI systems daily, named the structural consequence: “The whole forward-deployed engineer concept, I think, is for real. Every agent needs a human.” The difference is what kind of human: not someone to operate a tool, but someone experienced enough to know when the tool is doing something subtly wrong. That 10 percent, Emile’s estimate of the experienced reviewer’s contribution, is what saves thousands in model costs.
When the bottleneck moves
The practical implications of the human-AI collaboration model extend beyond code quality. They shape how teams should think about process, tooling, and resource allocation.
Emile described a specific dynamic: using a capable but not top-tier model combined with an experienced human reviewer yields better outcomes than using a top-tier model alone. The human review that catches missing elements in 30 minutes saves more than the premium model would cost. This isn’t a small efficiency gain; it’s a fundamental reframing of where value in the development process actually lives.
The productivity implications are significant. Development was, for a long time, the constraint: the long pole in the tent, the function that paced everything else. If that constraint loosens by a factor of 10 to 100 (Emile’s estimate of the potential productivity gain), then the bottleneck moves. It moves to product thinking: to the quality of the problem definition, the clarity of the intent, the judgment about what to build at all. The teams that benefit most from AI-driven productivity gains are those that already have strong product thinking. The gain amplifies what’s there, not what’s missing.
This is increasingly referred to as taste in the AI tooling world: the capacity to judge what should be built, to recognise when a generated output is technically correct but directionally wrong, and to know which of ten options is worth developing. Michael Truell, who built Cursor, framed the shift precisely: “We’ll move a little bit from carefulness, and a little bit more towards taste.” The observation comes from a different industry vantage point, but it names the same thing Emile’s experience provides: not the ability to write the code, but the ability to know whether the code is right.
From his own building and experimenting, Emile has arrived at an observation that reshapes this further: spec-driven development “is being taken too literally as a developer tool. I actually think it’s a team tool. I think it becomes the communication layer that the team uses.” If the spec aligns PM, UX, developer, and QA, not just instructs the AI, then the bottleneck doesn’t just move to individual taste. It moves to the quality of shared understanding. The artefact that matters most is no longer the code. It’s the document everyone can read, challenge, and own before a line gets written.
This connects to the opportunity specifically for AEC product builders. The industry has historically struggled with long development cycles that created enormous switching costs once a decision was made. If you can generate 100 different product requirement documents instead of one, build and test variations quickly, and use real usage data to select the best path, then the cost of being wrong early drops significantly. Experimentation becomes feasible in a way it wasn’t before.
Emile is specific about what this looks like in AEC. A hospital project comes with rigorous specifications: building codes, room books, and compliance requirements that often contradict one another across 10 different standards. Feed all of that into a system and instead of one design direction debated for weeks, you get ten options overnight, all buildable, all code-compliant, all costable. The conversation shifts from resolving contradictions by hand to choosing which two paths are worth developing further. “What if you could actually run all those experiments at the same time?” The bottleneck moves from execution to judgment: which options matter, and why.
That shift has an unexpected consequence for teams. Emile’s observation from building in practice: not less collaboration, but more. “I am seeing more collaboration. I am seeing more need for product managers and developers, not less — the UX, the PM, the scrum master, the developer, QA all working closer together.” When the drafting is automated, the conversation it previously consumed becomes available for something harder: choosing between options, not producing them.
Everything downstream needs rethinking
Emile raised a question that deserves more attention than it typically gets in AEC circles: if development productivity increases by 10x to 100x, do existing processes still make sense?
The answer is probably no. Scrum was designed around development as the constraint. Kanban may be a better fit for a world where the bottleneck has moved. But the scope of rethinking doesn’t stop at the development process: marketing, sales, approvals, compliance review, and procurement all move at speeds calibrated to the old constraint. When development accelerates dramatically, the surrounding processes become the new friction. Organisations that adopt AI for development without rethinking these downstream processes will find they’ve built a faster engine inside the same chassis.
This is the tension that the HBR research on AI and knowledge work identified clearly: AI doesn’t simplify work; it expands scope. Product managers begin writing code. Researchers take on engineering tasks. People attempt work they’d previously outsourced or avoided. Without intentional recalibration of norms and pace, this intensification leads to burnout, not just productivity. Keeping moving and keeping learning isn’t motivational advice; it’s a structural requirement for staying functional in an environment where the goalposts are genuinely moving.
The cost anxiety that follows is understandable but often aimed at the wrong target. Emile is direct about the order of operations: “Teaching a robot to wash dishes is going to make you a lot of money. But to get to the point where a robot can wash dishes, you’re going to break a lot of dishes. If you start worrying about the number of dishes you break, you’ll never get a robot that can wash dishes.” Cost optimisation is a second-order problem. The first-order problem is learning to use the tool well enough for the costs to be worth optimising.
Emile has a name for AEC’s current pattern: “AI stupid pet tricks.” The industry’s instinct is to deploy AI to solve one visible problem, show the result, and call it transformation. The harder shift, rebuilding workflows around what AI makes possible rather than layering it on top of existing ones, is the one most organisations haven’t started. Erica Brescia identifies the structural consequence in The new founder mode: companies that win in this era won’t be those that adopted AI as a layer on existing processes, but those that rebuilt their operating systems around it. The bifurcation is already evident; most AEC organisations remain firmly in the supplementary-tooling camp.
The instinct toward methodical execution and optimised process is understandable. It is also the wrong gear for this moment. The builders who are making progress are the ones experimenting, not the ones waiting for the right framework. Peter Steinberger, creator of the AI agent OpenClaw, arrived at the same conclusion from his own building practice: be playful, and allow yourself time to improve.
The surfing moment
A colleague once described the current AI moment in AEC with an analogy worth repeating. Most industry leaders right now are swimming in the ocean, making money, enjoying the conditions. A few are watching for the swell. The swell is here. During the paddling phase, it feels like you’re not making progress: the effort is real, the results are incremental, and the horizon doesn’t seem to be getting closer. But when the wave breaks, the separation happens fast.
“AI won’t take your job. But someone using AI better will.” ; Emile Kfouri
The point isn’t that urgency should produce panic. Emile’s disposition in this conversation was genuinely optimistic: excited about what’s possible, grounded about what it requires. But the optimism is conditional. It belongs to the people who are in motion.
For AEC builders specifically, the conditions right now are genuinely favourable: the tools are accessible, the barriers to building are lower than they’ve ever been, and the ability to test ideas quickly is real. The question is whether the people with the deepest industry knowledge (those who understand workflows, procurement constraints, regulatory requirements, and the specific reasons why AEC is resistant to change) will enter the building phase before the window narrows.
The precedent is consistent. When VisiCalc appeared, the first professional to use it on a real job did a week’s spreadsheet work in half a day, sat on it, delivered a day early, and charged more. They didn’t tell anyone which tool they’d used. Emile draws the same arc with Revit: early adopters kept quiet because the edge was real; once word spread, you had to tell clients you were using it or you were behind. AI is following that arc, compressed. The firms that recognise what they’re holding right now are still in the quiet phase; history suggests that interval is shorter than it appears.
Platforms are already moving toward agentic AI that replaces workflows entirely. The tools being built today by people with genuine domain depth are the ones that will matter when the wave breaks; the ones built as feature wrappers around APIs will be absorbed. Tiago, founder of DataGrid (acquired by Procore), drew the line clearly: “AI is supposed to do the work of the person, not just help you do a thing.”
The loop that closes
The three dynamics this conversation surfaces are not independent. They form a cycle, and understanding the cycle matters more than any of the arguments in isolation.
AI’s productivity gains are proportional to the experience directing them. The reason Emile can build effectively without seeing a line of code is that two decades of debugging knowledge and architectural judgment shape every instruction he gives. The tool doesn’t create that judgment; it multiplies it. The firms that capture the most from AI development speed are the ones with experienced practitioners directing it, not the ones that have stripped seniority out in favour of cheaper execution.
Those same experienced practitioners are also best positioned to recognise what the tools make possible. The hospital scenario, ten buildable options overnight from a specification, is not a speculative future: it is a product problem that requires AEC domain knowledge deep enough to define what “buildable” actually means. The tools can generate options; only someone who has watched a project fail knows which constraints matter. Depth and capability are not separable advantages. They compound.
The window is the part that closes. The VisiCalc-to-Revit arc is not coincidental: it is the consistent sequence by which productivity tools move through professional markets. Early movers capture a disproportionate advantage while the tool is still differentiating; once it becomes table stakes, differentiation shifts to other factors. The interval between those two phases is where practice compounds fastest: not just using the tools, but developing the instincts that only come from building real things with them. Waiting doesn’t mean missing the first-mover window; it means entering the second phase with less accumulated practice than the people who moved.
Emile started coding again after 20 years away. Not because someone told him to. Because he recognised that the depth he had been accumulating had just become newly deployable, and that the window for that combination was shorter than it looked. That recognition, more than any specific tool or process, is what this moment is pressing on the people in a position to act.