Blog
Building Humaniza IRIS with AI
Humaniza IRIS is one of the places where the thesis behind humaniza.dev has to prove itself: not in theory, not in slides, but in real construction and validation close to clinical routine.
Published on
Apr 03, 2026
Reading time
4 min read
Author
Equipe Humaniza Health
Categories
Share
On this page
Humaniza IRIS is one of the places where the thesis behind humaniza.dev has to prove itself: not in theory, not in slides, but in real construction and validation close to clinical routine.
IRIS only makes sense if it stays connected to the context that created it.
What IRIS represents
For me, IRIS is not just another project. It is a direct test of a larger question: how far can clinical and operational context be turned into product with the help of AI while preserving clarity, responsibility, and execution rhythm?
That matters because AI makes many things easier, but it also encourages a common mistake: building too fast without understanding the problem well enough. IRIS forces me to do the opposite. Context first. Then language. Then structure. Only after that, implementation.
How AI enters the process
In IRIS, AI is not ornamental. It works across multiple layers:
- organizing reasoning;
- comparing workflow options;
- structuring interfaces and forms;
- accelerating technical drafts;
- revising naming and copy;
- reducing friction between hypothesis and execution.
That saves time. But the real gain is not just speed. The real gain is keeping the process moving even without a traditional product and engineering team behind every step.
When the question is well formed, AI reduces the initial friction of execution. When the question is weak, it tends to generate fluency without direction.
Where AI helps most and where it helps less
| Situation | Where AI helps most | Where AI helps less |
|---|---|---|
| Initial formulation | opening paths and reducing inertia | deciding which problem actually matters |
| Product structure | exploring flow, copy, and interface shapes | deciding what really fits the clinical routine |
| Delivery | accelerating technical drafts | taking responsibility for what reaches production |
What remains human
Even with AI at the center of the process, some parts remain essentially human:
- understanding the real weight of the problem;
- deciding what is actually a priority;
- noticing when a solution looks good on paper but does not fit the workflow;
- sustaining language consistency;
- and taking responsibility for what reaches production.
If I outsource that to AI, the product loses fit. IRIS only makes sense if it stays connected to the context that created it.
The build loop
- 01
identify real friction
- 02
name the problem clearly
- 03
break the problem into smaller pieces
- 04
use AI to explore flow, copy, structure, and technical paths
- 05
choose a minimal viable direction
- 06
test, revise, and cut excess
It sounds simple when written down. In practice, it involves rework. Many times, the first AI response is useful enough not to discard, but generic enough not to accept. The real work lives in editing, correcting, and feeding context back until the result feels less like a demo and more like a product.
Where it helps less
It helps less when domain ambiguity is still unresolved.
If the problem is not clear, AI answers with fluency, but not with direction. And product without direction is just surface-level output. IRIS keeps reminding me of that whenever a polished answer tries to hide a question that was never defined well enough.
Fluent text is not proof of understanding. In IRIS, problem clarity still has to come before response speed.
FAQ
Why this matters for humaniza.dev
Building IRIS in public matters because it shows the kind of work I want to document here: less performance of authority and more clarity about how things are actually built.
If humaniza.dev is going to be valuable, it has to show real build logs, not only well-packaged ideas. IRIS is one of the first proofs of that.