No-Code Manager Transformed Hospital Software Factory with Agentic AI — and the Account is Surprising

No-Code Manager Transformed Hospital Software Factory with Agentic AI — and the Account is Surprising

Imagine leading the software factory of a hospital network for 15 years, being responsible for a legacy system running in over 40 units, having a small team — and never having written code professionally. Now imagine using agentic artificial intelligence not as a technological toy, but as a rigorous method for real transformation. This is exactly what mdemian1972, a manager identified only by the nickname on the TabNews platform, did — and the account he published is generating intense debate in the Brazilian technology community.

The story is not about miracles. It's about method, productive skepticism, and the courage to expose an unfinished process to public scrutiny.

---

The Scene: Small Team, Giant System

The starting point is brutally honest. A system with over a decade of existence, running in production in dozens of hospitals, maintained by a lean team. Any poorly calculated change can impact critical operations. Any technological paralysis means lagging behind in a sector that is being rapidly reconfigured by AI.

When the agentic world scaled in 2025, the question the manager asked was not “Is this cool?”. It was more pragmatic and more difficult: “Can we get this to work without stopping the operation?”

This distinction in posture — from naïve enthusiasm to operational questioning — already sets this account apart from most AI adoption cases out there.

---

The Method: Many Small, Verifiable Experiments

Instead of a large proof of concept — that monumental project which takes months, costs a lot, and often dies before reaching production — the manager adopted a radically different approach: dozens of isolated and disposable projects, each one addressing a specific hypothesis.

The questions were surgical:

• Can this type of module be developed by AI with quality?
• With which architecture does the result sustain itself in the long term?
• What is the actual quality of the generated code? And of the automated tests?

Each project existed to answer a question. What worked became a documented standard. What failed cost little and taught quickly. It’s the logic of a portfolio of bets applied to technological adoption — many small and verifiable bets instead of one big blind bet.

The manager himself defines the contrast well: “This is the opposite of 'vibe coding'. It's factory method applied to the very adoption of AI.”

---

The Stack that Emerged from the Experiments

After rounds of experimentation, a technical pattern consolidated. It's worth noting because the choices are deliberate and have justification:

• Monorepo: Bun + Turborepo
• Frontend: React + TanStack Router + Tailwind/shadcn
• Backend: Hono + tRPC
• Data: PostgreSQL + Drizzle
• Testing: Vitest + Playwright

But the most controversial choice — and probably the most interesting for technical debate — was in the agentic field: not using LangChain or LlamaIndex. Instead of adopting a consolidated generic framework, the team built their own agentic workflow around Claude Code + Skills, with traceability and human review checkpoints.

The bet is explicit: method and control instead of framework abstraction. It’s a choice that can be discussed, but it's not naïve — it's architectural and has a clear intention.

---

What Was Actually Built

Here, the account gains even more credibility by not inflating the results. The manager is direct: he moved from experiments to the conversion of modules of the real hospital system. Two fronts have already been developed.

But he is careful to calibrate expectations: “It's a work in progress, it’s not 'everything in production in the 40+ units'. It’s real construction, not a mock-up — but it’s a process, not a victory flag.”

In an ecosystem saturated with exaggerated success cases and presentations of still hypothetical results as if they were consolidated achievements, this honesty is, paradoxically, one of the most convincing elements of the account.

---

The Surprises — Including the Uncomfortable Ones

Three points surprised the manager throughout the process, and all have relevant implications for any team thinking about similar adoption:

1. Speed and quality above expectations — coming from someone who was a declared skeptic. It is not enthusiasm from an evangelist, it’s surprise from someone who went in with low expectations and came out with a positive assessment.

2. The bottleneck shifted — from "writing code" to "specifying well, reviewing, and measuring." This has huge implications for how development teams need to be structured and which skills gain value.

3. The role of the architect became more important, not less — working side by side with André Lins, the operation's architect, the manager observed that AI did not diminish the importance of architectural thinking. On the contrary, it amplified the need for quality technical decisions — because now those decisions multiply at a much greater speed.

---

The Criticisms He Anticipates

One of the most intellectually honest parts of the post is the section where the manager himself lists where he expects to be questioned:

• “A non-programming manager has no way to evaluate the quality of what AI generates.” He himself classifies this as a legitimate criticism and invites debate.
• Long-term maintenance of AI-generated code — a question that the field still does not have a solid answer for.

These are not rhetorical objections to be easily rebutted. They are real tensions that any serious AI adoption operation will face. The fact that the manager puts them on the table instead of sweeping them under the rug is, in itself, a sign of maturity in the approach.

---

Why This Account Matters Beyond the Specific Case

What makes this story relevant is not the technology itself — Claude Code, Hono, and Drizzle are well-known tools in the community. What is remarkable is the adoption model:

• Skepticism as a starting point, not enthusiasm
• Small and disposable experiments instead of big bets
• Deliberate architecture instead of uncritical framework adoption
• Transparency about what is not yet ready
• Human review as part of the process, not as an exception

At a time when much of the discourse on AI swings between catastrophism ("it will end all jobs") and triumphalism ("it solves everything automatically"), this account offers something rarer: an operational, granular, and honest view of how technology fits into a real operation with real constraints.

---

The Debate to Come

The publication on TabNews generated immediate engagement, and the author himself explicitly invites grounded criticism. The questions that will certainly dominate the comments are exactly the most important ones: how does a non-technical manager ensure the quality of the generated code? How is agentic code maintained in critical production over the years? Is it worth reinventing the agentic workflow instead of using consolidated frameworks?

There are no easy answers. But the fact that these questions are being asked seriously — by someone who has 40 hospitals depending on the answers — is exactly the kind of conversation that the hospital technology sector needed to start.

The factory's turnaround is underway. The method, at least, is in public debate. And that is already more than most deliver.