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.
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 →