You can build something that looks functional in a weekend now. Sometimes it actually is functional. The barrier to building software has never been lower — and that changes what is scarce. When anyone can build, the value moves to judgment: knowing what is worth building, and where it should not be built at all.
Whether or not you are delivering real value to people is now completely detached from your ability to build something. AEC software is a sharp example of this. So the question we spend the most time on at Kestrel Labs isn't "Where should we use AI?" It's "Where shouldn't we?"
The barrier collapsed
I am not exaggerating the speed. I built our entire website myself in about ten days using Claude Code — an incredibly fun creative exercise that also saved us a meaningful amount of money. The marginal cost of producing software is heading toward zero, and that is genuinely good news for small teams.
But "I can build it" and "this should exist" are different sentences. When the cost of building collapses, the things that used to be implied by the effort — care, discernment, the decision to do it at all — stop being implied. They have to be chosen on purpose.
Building is not the same as value
A working demo proves you can ship. It says nothing about whether the thing should be trusted. In a low-trust, low-stakes domain, that gap is forgivable — you iterate in public and the worst case is a bad afternoon.
Building codes are not that domain. The code is the legal basis a project is permitted against. A tool that is fluent and fast and confidently wrong is worse than no tool, because it spends the one thing the industry runs on: trust. The bar for taste and accuracy has to rise exactly as fast as the barrier to building falls.
The question we ask most
For those who don't know what we do: Kestrel digitizes building codes and puts them inside the BIM model, so you can check compliance continuously while you're still designing. The obvious instinct is to ask where else we can add AI. We deliberately invert it.
AI is incredibly good at processing and standardizing large amounts of information. That does not mean it belongs everywhere. The harder, more useful conversation our leadership team has — driven by our CTO and kept honest by the two licensed architects on staff, who describe themselves as AI skeptics or Luddites depending on the day — is the opposite one:
Where do we not put AI?
Probabilistic where it fits, deterministic where it counts
There are places where a probabilistic system is exactly the right tool, and places where you still want a trusted, auditable, deterministic one. The skill is telling them apart.
In a high-trust, high-risk industry, there are places where a probabilistic system cannot and should not be trusted — at least today. The answer that comes out at the end has to be one an architect can stand behind with a stamped set, not one that merely sounds right.
The four design parameters
Over time we have compressed that judgment into four parameters. Each one is testable: you can sit in a demo and check it. They apply to any system whose output a professional has to stand behind, in any high-liability domain, not just ours. A product that fails one of them can still be useful. It just cannot be load-bearing.
Repeatability
Identical inputs return identical outputs. Run the same check a thousand times, get the same finding a thousand times, and let people watch you do it.
Traceability to authority
Every finding cites the specific source text it rests on, at the clause level. A paraphrase of the code is not the code.
Row-level auditability
The full reasoning behind every result is open for inspection. Someone who wants to open a 10,000-line report and verify each finding by hand can do exactly that.
Differentiated confidence
Interpretive output looks visibly different from determinate output, so a reasonable inference is never dressed up as a settled requirement.
These four parameters are what let us draw the line inside the product, and the line falls in the same place every time. AI does the reading: converting enormous volumes of unstructured legal text into a structured store the checks can run against, work that is high-volume and verifiable. Rule logic does the determining: the moment the system asserts that something is or is not true. And AI does the explaining: what a violation means, why it matters, and how to fix it without creating three new problems elsewhere in the building. Ingestion, determination, explanation. The middle one is where trust lives, and it is the one we keep AI out of.
The point of all four is the person who signs the drawings. Every parameter exists so that when an architect stands behind a set, they are standing on something they can see. (I went deeper on these, and on where they came from, on the What’s Left? podcast.)
That discernment doesn't come from knowing the most about AI
Here is the part that gets missed. For AEC, you cannot make these calls from knowing the most about AI. Knowing where a probabilistic system belongs in a building-code workflow is a question about buildings, liability, and practice — not about model architectures.
That level of discernment, risk assessment, and taste comes from decades of practice — from licensure, from painful permit comments, from long conversations with clients and contractors, and from making unbelievably stupid mistakes late in a project. ("We don't have a water fountain here" is a silly reason to delay a permit, and it is also exactly the kind of thing that delays permits.) That collective, hard-won judgment is more valuable now than ever, not less.
It is why the architects on our team aren't just the voice of the customer — they are the level of discernment that decides what we build, what we refuse to automate, and what "right" even means for a given check. Please don't all leave architecture for tech. We still very much need architects.
Be subtractive, not additive
The honest answer, in 2026, is that you can put AI into nearly anything. And you may not be happy if you do. When everybody can build everything, the result is a sea of noise — and the same is true inside a single product that bolts AI onto every surface.
So we try to be subtractive rather than additive. The discipline is removing AI from the places it doesn't earn its keep, and reserving it for the places where it genuinely changes what's possible. Be intentional about what you make — and about what you choose not to.
The future is very long
None of this is a prediction that AI won't get there. The future is very long. I don't know where these models will be in five years, and our line between probabilistic and deterministic will move as they improve. Drawing it carefully today is not pessimism — it's how you stay trustworthy long enough to still be here when the line moves.
One of the most important product questions isn't how much AI you can add to a product. It's whether AI belongs in that part of the product in the first place. We ask it constantly — and we think any serious team building in a high-trust industry should too.
We've written about what this looks like in practice — why every flagged issue has to carry a verifiable citation: Citations, not summaries →
If you want to see where we drew the line on your own model: Schedule a demo →