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.

Why humaniza.dev exists

Published on

Apr 03, 2026

Reading time

3 min read

Author

Equipe Humaniza Health

Categories

Product backstage
Doctor-builder

Share

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.

Note

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.