Blog
Why humaniza.dev exists
humaniza.dev exists to document, in public, the real routine of building Humaniza Health solutions with AI as leverage, without hiding the friction, rework, and limits of the process.
Published on
Apr 03, 2026
Reading time
3 min read
Author
Equipe Humaniza Health
Categories
Share
On this page
humaniza.dev exists to document, in public, the real routine of building Humaniza Health solutions with AI as leverage, without hiding the friction, rework, and limits of the process.
“Less performance of authority. More clarity about how the process actually happens.”
The starting point
I did not create humaniza.dev to perform as a developer.
I created humaniza.dev because I needed a place to document, honestly, the real routine of building Humaniza Health products with AI as leverage. No artificial polish. No template narrative. No pretending the process is linear.
My background is in medicine. My context is clinical and operational. The question was never “how do I become a traditional software engineer?” The real question was different: how do I turn real context, practical decision-making, and operational pain into software that reaches production?
That is where humaniza.dev comes from.
What this platform is trying to show
I want to show the full process:
- where the idea started;
- what looked promising at first and later proved weak;
- what AI actually accelerates;
- what still depends on human judgment;
- where rework shows up;
- and how a product moves from discourse into routine.
Humaniza Health products like Humaniza IRIS and Humaniza Clinical do not emerge in a vacuum. They come from real friction, real language, real constraints, and imperfect decisions. Documenting that in public is a way to give context to what is being built.
humaniza.dev does not exist as a programming school, a stack showcase, or a disconnected hack lab. It exists to document real construction.
The role of AI here
For me, AI is not decoration.
It is execution infrastructure. It helps me think better, test faster, organize hypotheses, shape interface, revise copy, explore technical paths, and shorten the distance between intention and delivery. But it does not replace priority, responsibility, or clinical and operational judgment.
The mistake in a lot of AI discourse is selling magical autonomy.
What interests me is something else: using AI as a serious copilot to expand building capacity without giving up responsibility for what is being built.
What you will find here
You will find backstage material.
You will find posts about product, build logs, architecture decisions, trial and error, prompting, automation, copilots, and operations. You will see what worked, what failed, and what had to be redone.
You will also find a specific perspective: someone who did not come from a traditional engineering path, but decided not to use that as an excuse to avoid building.
What you will not find
You will not find a narrative of perfection.
You will not find the idea that everything can be solved with a prompt. You will not find artificial authority. And you will not find content produced to look more sophisticated than the real work actually is.
If humaniza.dev is useful, it will be for a simple reason: it shows the process as it is.
The commitment
My commitment with this platform is to document real building.
If there is progress, it should appear.
If there is error, it should appear.
If there is rework, it should appear too.
Because the value of humaniza.dev is not in looking finished. It is in showing, clearly, how product, AI, and human context can meet in the concrete work of turning software into reality.