Audio article narrated by OpenAI
I keep noticing the same reflex in this industry: when something breaks, we lay a new layer over it instead of removing the cause. The layer is almost always the same shape now: a fresh AI bolted on top of a symptom, and then, soon after, a second one to manage the mess the first one made. Every fix becomes a stratum over the last, and none of them touches the thing underneath. I went into my conversation with Francisco Maranchello wanting to test a suspicion: that the more interesting move in AEC right now is not another layer, but a system built to hold the mess instead of hiding it, and that his career is one long argument for exactly that.
About Francisco Maranchello
Francisco Maranchello trained as an architect at Universidad Blas Pascal in Córdoba, Argentina, before co-founding SUBOX, a modular construction startup, while still in college. He joined AEC Resource, a large BIM consultancy, where he helped build AEC Lab, an internal innovation arm; AEC Resource and AEC Lab later merged into Voyansi, acquired by Hexagon and now operating as Hexagon Multivista. From there, he co-founded e-verse, a custom AEC software company, spending nearly five years building bespoke tooling for AEC firms and startups. He is now co-founder of Radical Labs, building Conduit, an AI platform for generating, versioning, and deploying AEC workflow automations, and writes Concrete Code, a Substack on software, architecture, and the space between them.
—
“You had the pirate, who’s really moving fast and breaking things and vibe coding and testing stuff. And then the other guy who comes in at certain points to bring solid foundations for the pirate to keep doing their thing. Software developers will have that role of being the adult in the room.” Francisco Maranchello
—
I’ll return to the pirate and the adult later; that framing became the crux of the whole conversation. But I want to begin with the diagnosis. Francisco spent nearly five years at e-verse, the custom software company he co-founded, being paid to patch this fragmentation by hand.
“When you’re doing services, many times you’re customising everything so much that it’s very hard to turn that into a product. Especially in the AEC industry, every company has their own workflows and ways of dealing with problems, with models, with technology. It’s not as standardised, I guess, as other industries.”
Five years of building one bespoke integration after another teaches you where the disorder lives. It is rarely in the tools themselves; it is in the seams between them: the exports that quietly drop data, the naming conventions no two firms share, the model that has to be rebuilt because the last team structured it for a different downstream use. Francisco is not the first builder I have interviewed to reach this from inside the work; Luigi La Corte arrived at the same tension at Provision, that the customisation clients pay for is exactly what makes the result impossible to reuse. So when Francisco describes the wider state of AEC tooling, it lands as a finding, not a complaint:
“All of the platforms we use and the automations we create for those platforms are very scattered and disconnected, and that’s always a painful thing. And now we are adding even more tools on top of that, so it’s even more disconnected, with more layered tools that don’t really talk to each other.”
The contracts that grow longer each time we ask AI to draft them, the drawing sets that swell with duplicated information because regenerating them costs nothing: both are symptoms of the same underlying disease, tools and data that were never built to talk to each other, papered over with one more layer. What makes Francisco worth listening to is that, across four companies, he has been running the same counter-move against that disease, and the move predates the current AI wave by a decade.
The move under the layers
Strip his career down and the same instinct shows up every time: find where variance is being absorbed by repetitive manual work, and push that absorption upstream into a system that can hold it. It is worth being precise about what that repetitive work usually is. It is seldom the visible task; it is the coordination around it, the manual reconciling, re-exporting, and checking that exists only because our tools and teams each carry their own context and none of them shares it. That coordination layer is where thin margins and lost weeks quietly accumulate, and it is the first thing Francisco has tried to move upstream at every stop in his career. He learned it on a renovation project for the Buenos Aires city government: a 20-person team with a year to produce BIM models and quantity takeoffs for roughly 2,000 homes in a dense, informally built part of the city.
“We started automating stuff with a friend of mine, and I saw the way he was impacting how everyone on the team worked. So I wanted to get in on that, and that’s where I started mixing both, more directly.”
Notice what moved him: the sight of one person’s tooling rippling across a whole team’s output, spreading faster than anyone had planned. His first attempt to build that ripple deliberately was SUBOX, a modular-construction startup he co-founded while still in college, pairing factory-made components with a platform where clients could configure and order modules themselves.
“It was trying to automate repetitive processes… industrialising a lot of parts in the building process. There have been a lot of companies doing that pretty successfully since then, so the direction was right in some way.”
Underneath sits a bet about leverage he traces back to first principles:
“Even the most successful architects build a hundred buildings in their entire careers. Two hundred, three hundred maybe. And that’s a really small portion of the built world. So I figured I could have a bigger impact by leveraging technology and designing the tools that all the architectural firms use.”
A factory at SUBOX, an automation team at AEC Lab, custom software at e-verse: each was a different container for the same move. Conduit is the current one, and it is the first that tries to make the container itself the product.
What he built
Conduit is, in Francisco’s own words, “kind of a productised service, and a harness around the AI.” The second half of that phrase is the one that matters. You describe a workflow in a chat and the platform writes the automation; the automation, though, is not the product. The product is the harness: everything wrapped around the model that decides what it can see, what it is allowed to touch, and what happens when it fails.
The first thing that surprised me is what it is not. Because it starts with Revit, I assumed it lived inside Revit; it doesn’t.
“We are actually not tied to Revit. It’s a web platform, so it’s not really desktop software, and it doesn’t live inside Revit. We just started with add-ins and Revit automations because it was a clear wedge, where many users are. But we already added ACC, which is now Forma, we also added AutoCAD, and we are working on adding Procore and Tekla as well.”
That is the decision that separates a platform from a plugin, and it echoes Andriy Mulyar’s argument for staying horizontal rather than chasing every workflow as its own point solution: Revit is a wedge, not a ceiling. Targets get added one at a time, so the system earns real depth in each before taking on the next.
The part that is hard to copy is underneath. Every target ships with a template package built from years of his own add-ins and automations: multi-version support, cloud compilation pipelines, agent-readable API documentation, and embedded telemetry that keeps every deployed app current and surfaces failures before anyone digs through logs.
“It doesn’t start from scratch every time. I’ve been developing many of those templates for many years, across these different experiences. That’s one of the main differences between this and just using vanilla Claude Code or Codex, because it has a really solid foundation.”
This is where his back catalogue stops being biography and becomes moat. The same accumulated craft that Emile Kfouri described as raw material rather than obsolescence, two decades of instinct redirected through AI, is what lets Conduit start each app from a solid foundation instead of a blank prompt. This is also the part the industry keeps looking straight past. Everyone argues about which model to use; almost nobody talks about the scaffolding around it, even though the scaffolding is what decides whether the model returns something you can deploy or something you have to babysit. The same model will pass or fail the same task depending on the harness it runs inside. Francisco makes the point himself when he separates Conduit from “vanilla Claude Code or Codex”: the model is largely interchangeable, and the durable advantage sits in the harness. The non-standardisation that made e-verse’s work impossible to productise does not vanish here; it gets absorbed into that harness. Which is the move again: variance pushed upstream into a system that holds it.
The gap it’s built to hold
Here is the hinge. Francisco has stopped writing code himself, and he means that literally:
“For the last six or eight months, I haven’t manually written a line of code. We do check the pull requests, just to be sure some things make sense when it’s really something specific. But in general, I don’t write code manually, and many times I don’t even look at it. I always test it.”
Multiply that across an industry and you get the problem he is building against. He used to think this AI wave would kill software developers; now he thinks the opposite, because he keeps watching people generate a “massive snowball of debt and problems” faster than anyone can maintain it. This is the pirate and the adult I promised at the start. The pirate ships fast and breaks things; the adult arrives afterwards to lay the foundations that let the pirate keep moving. Francisco’s gloss on that second role is the part worth holding onto: software developers become “the adult in the room, actually seeing what people are doing with AI and helping them make it work, because this vibe coding thing creates a lot of downstream problems.”
Karpathy’s argument that vibe coding is already obsolete, that stripped of its vocabulary it is simply product management, points at the same vacancy: when execution stops being the bottleneck, judgement about what is worth building becomes the whole game. Most tools wait for a human adult to show up afterwards and clean up. Conduit’s bet is to build the adult into the substrate:
“Conduit is kind of a solution to that, where firms will have more control about what they’re coding using AI instead of just vibe coding it in whatever format and shape. Having a controlled environment where they can do it safely, with production-grade code and managing versioning and the deployments and telemetry, all in the same platform.”
That is the whole thesis in miniature. The pirate is the person vibe coding a script that works for one project; the gap is what happens three months later, when it quietly breaks and no one owns it. Governance baked into the platform, in the form of versioning, telemetry, and production-grade output, is an attempt to close that gap structurally rather than heroically.
Whether the value is real
I want to be careful here, because it would be easy to narrate this as a finished success, and it is not one yet. Conduit is a young product. Francisco and his team opened it to a handful of pilot companies not long ago, and almost everything he knows about whether it works, he is finding out right now, in daily conversations with those users. By his account, the pilot base has widened rather than stalled since we spoke: teams putting it to real use on their brittle internal tools, an approved project-team trial, and a few more mid-sized firms asking to run their own. That is early traction, not proof, but it is moving in the right direction.
What he has learned so far is mostly about who shows up. The most intensive testers are people who were already automating:
“Some of the people testing it more intensively are people who were already building automations, but in a very bespoke or brittle way, where they had scripts that would break, and they would struggle to maintain them, version them, deploy them. All the usual pain points, which basically Conduit is built around to solve.”
Across the early pilots the same user keeps surfacing: teams that need internal tools but struggle to create, deploy, maintain, and own them. Conduit has not tested repeatable value at scale, but that consistency is a promising signal; it means the tool is being pulled toward a real and recurring pain rather than pushed at a hypothetical one. His method is deliberately impatient:
“That’s the importance of launching fast. We worked on it a month and a half, then opened it up and people started testing it. When you test it with real people using it for real workflows, you can’t predict all of that. The earlier you ship, the better, because it will inform you what you should actually be building.”
Shipping that early is itself the test. Each day of pilot use tells him which parts of the workflow he guessed right and which he will rebuild, and he is rebuilding in the open rather than polishing in private.
None of this proves the value. It is a founder weeks into a public pilot, testing a hypothesis against live users and adjusting fast, which is exactly how he learned the move in the first place. The Buenos Aires automation did not prove itself in a business case; it proved itself by rippling across a team until everyone was using it. That is the bar Conduit has to clear, and it has not cleared it yet. What is visible so far is the mechanism that will tell him whether it can, and that mechanism is running.
What would prove it
So I pushed him, at the end, on the structural question: what has to change in the industry for a tool like this to matter? He was honest that he did not have the whole answer, but he named the condition:
“It’s good to think about horizontal platforms that really integrate with everything else and can talk to all platforms, and help unify all that scattered data and scattered decisions and different knowledge that’s siloed in very different environments. There are some platforms out there trying to do that, like Speckle. But really having an intelligence layer on top of all that could be a great thing to aim for.”
I agree with the direction, and I would go one step further about what it demands. A horizontal intelligence layer can only orchestrate across tools if the tools underneath it are legible to an agent in the first place, and most of AEC’s data was never structured to be read that way. One recent analysis of agentic infrastructure makes the point sharply: the substrate was never built to carry the load that delegation puts on it, and it cannot be bolted on after the fact. The lesson from the last platform shift is that the winners redefined the unit of value the system was organised around, the element instead of the file, and then owned the couplings between layers rather than any single tool. AEC has never agreed on its own unit of value, which is why an agent asked to reason across a project finds files it can open and almost nothing it can understand. Before we can have the intelligence layer, we have to be willing to structure the data underneath it, and the industry’s instinct is to skip that step and add the layer anyway. Which is where we came in.
It matters to be exact about which of these problems Conduit is solving, because they are easy to conflate. Conduit is not the intelligence layer that reads a firm’s ontology and reasons across its projects. It is the harness one rung down: the thing that lets a firm write and ship trustworthy automations against the tools it already runs, faster and more safely than a lone developer wiring scripts together at midnight. That is a real and valuable job, and it is deliberately a smaller one than solving the industry’s data problem. The harness is the floor under the pirate’s speed; it does not decide what gets built; it makes sure that whatever gets built can bear weight. What it does not do, on its own, is make the building legible.
The version of the legibility problem I find most credible is small. I keep returning to Palantir’s insistence that you earn an intelligence layer by first defining your ontology, the unglamorous, agreed-upon map of what your entities are and how they relate. IFC tried to do that for the whole industry at once and drowned in its own complexity. A single firm, at its own scale, can define a small ontology that an agent can read, then connect it to the next one, rather than waiting for a universal standard that has never arrived. This is less a technical problem than a literacy one; the work is learning to define a thing cleanly and to capture the next project with the definitions the last one taught you. Skip it, and AI can chat about your documents but never reason about your buildings.
The asset that slows you down is the asset that saves you
Trace the arguments and they close into a single loop. The industry’s core problem is that AI keeps getting bolted onto broken workflows, so the real near-term value is connective rather than computational. Connection, in turn, is precisely what a 40-year incumbent already has and a fresh competitor cannot fabricate; it is the trust Ben inherited and refuses to spend. That trust is generated in the unglamorous proximity of picking up the phone and teaching the day course, and it is verified by deterministic engines that have been correct for 30 years. The same legacy codebase that can be complex to iterate on is the foundation that makes its answers safe to check against, which is why what slows it down and what keeps it safe are the same property viewed from two sides.
The deeper signal is about where defensibility lives once software becomes buildable on demand. When any competent person can generate a finite-element program, the feature stops being the moat and the relationship becomes it; when any agent can generate a plausible answer, the trusted engine to verify against stops being technical debt and becomes the asset. Both shifts point in the same direction: value migrates from what can be generated to what can be trusted. A practitioner who spent his career on the using side of the glass, and then crossed to the building side, turns out to be unusually well placed to see it, because he knows from the inside that what an engineer is really buying is not the calculation but the confidence to sign their name beneath it. The local judgment that caps the company’s size is the same judgment a global model cannot replicate, which means the ceiling and the moat are, once again, the same wall.