How an open-source HR system gets built, and how to check it

At MintHCM, AI agents write code under a fixed process with three human gates, and every change leaves four artefacts anyone can inspect.

The question behind this page is not whether we use AI. It is whether this project will still be alive and maintained in three years, and what you can look at to judge that for yourself.

What does agentic engineering mean at MintHCM?

It means an AI agent receives a whole task rather than a line of code to autocomplete. The agent reads the issue and the source, proposes a plan, writes the implementation, writes and runs the tests, and fixes what fails. People move from writing to deciding.

The distinction matters because “we use AI” covers both an autocomplete plugin and a process that runs a task end to end. Autocomplete speeds up typing. Agentic engineering changes who leads the task, and that is why it needs a different kind of control around it.

What evidence does each change leave behind?

Four artefacts, each with its own reader and each answering a different question. The plan is written before the first line of code. The verification report lists the tests run and, most important, what was not checked and why.

The code review report is produced automatically and read by a senior engineer against the code. The release-notes entry is the only public one – it ships with the release and stays there. The first three are internal, but they do not disappear: we collect and review them, which is how the process improves.

Where does a human say no?

At each of the three gates, and more often than you might expect. A share of the agent’s decisions still needs human correction. We do not estimate that; we see it in the artefacts each task leaves behind.

Three moments are fixed: plan approval, review of the change before it is committed, and acceptance testing. The agent does not save its questions for a gate – if halfway through it finds that a planned change would break two other processes, it asks immediately.

What can an AI agent access?

Only the systems a person connected for it. The scope of tools is agreed together with the plan for a task, not granted once and left open.

We arrived at that rule after a specific incident. A developer was working on one task while an access to another instance of the same system was connected at the same time. The agent concluded that, since it had access, it could analyse that instance, and started connecting. It was stopped immediately.

We describe it because it shows where the risk actually sits. An agent does not break security. It uses what was left open.

Why does this matter in an HR system?

Because MintHCM has more than fifty modules and most of them are connected. A change in recruitment can reach onboarding. A change in employment periods can reach working-time and overtime settlement. A change in positions can reach competency appraisals.

Code that is almost right is more dangerous there than code that is plainly wrong. Wrong code fails straight away. Almost-right code miscounts length of service by one day, and that surfaces only when somebody issues a document on it.

How much time does an agent actually save?

It depends on the complexity of the task, and it does not scale linearly. On a simple, self-contained change the developer’s own involvement drops sharply. We publish that as a direction, not as an average and not as a promise.

The measurement itself is approximate. No tool measures a developer’s time to the minute, and the figure excludes the final manual click-through and the tester’s work. It is easy to overstate: the METR study (2025) found that experienced developers working with AI needed 19% more time while being convinced they were faster. That is why we publish runs and artefacts rather than impressions.

How can you check this yourself?

In four places, without asking us for anything. This is the one thing a closed-source vendor cannot offer, even with a better process than ours.