Agentic Engineering
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.
In short
Agents do the typing; people keep three decisions: approve the plan, review before commit, accept the result. A share of the agent’s decisions still needs human correction, which is why the gates exist.
On this page
- What agentic engineering means at MintHCM
- How a single change moves through the process
- What evidence each change leaves behind
- Where a human says no
- What an AI agent can access
- What an agent will not do
- Why this matters in an HR system
- How much time an agent saves
- How you can check this yourself
- What changed in one quarter
- Frequently asked questions
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.
How does a single change move through the process?
One task, from request to release note. Green markers are the three places where a person decides. The fix loop is capped at three attempts: without a limit on cycles an agent can keep spending on attempts that lead nowhere, so after the third it stops and says where it got stuck.
Gate 1: plan approval
A person reads the plan before any code is written – the cheapest moment to say “not this way”.
Gate 2: pre-commit review
The diff and the code-review report are read before the commit. The senior engineer decides which comments are valid.
Gate 3: acceptance testing
A tester adds the cases the plan is missing and clicks through the rest by hand. The sign-off is theirs.
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.
We expect the correction rate to fall. We do not expect it to reach zero, and we do not plan to remove plan approval even if it does.
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.
What will an agent not do in MintHCM?
Three limits are worth knowing before you draw conclusions from the rest of this page.
It will not walk through a long HR process
Testing offboarding first needs an employee with completed onboarding, employment terms and an employment period. Browser tests handle structural changes today. That is the next target.
It does not know dependencies nobody wrote down
Some links between modules never reached the code or the documentation. A generated test will not catch them, so a tester still clicks those paths by hand.
It cannot see an instance that has drifted from the repository
The agent works on current code. A long-unupdated or modified deployment looks different, and fixes for those are planned by a person.
How do those limits move?
Artefacts from different tasks are collected and reviewed for repeating mistakes. In the last review, code review reports kept flagging that new action buttons did not check user permissions. That went into the implementation instructions and stopped appearing. Read this section as a list of things that should look different next quarter.
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.
This is not a private worry of ours. In the Stack Overflow Developer Survey 2026, 48% of developers said they trust AI answers when they can easily validate them, and only 16% extend that trust to most tasks outside important work decisions. The DORA 2026 report on the return on AI-assisted development, citing Stanford research, finds productivity gains of 35-40% on simple greenfield tasks, but often 10% or less on complex legacy code. It also names the time spent reviewing and verifying AI-generated code as a cost that is easy to overlook. A mature HR system is exactly that kind of legacy code.
48%
trust AI answers when they can easily validate them
Stack Overflow, 2026
16%
extend that trust to most tasks outside important work decisions
Stack Overflow, 2026
10%
or less productivity gain on complex legacy code, against 35-40% on simple greenfield tasks
DORA, 2026, citing Stanford
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 get wrong: in early 2025 METR found that experienced developers working with AI needed 19% more time while being convinced they were faster. In February 2026 METR said that result is likely outdated, but that its newer data is too unreliable to put a figure on the change. 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.
- The repository, with authorship preserved on every change
- Technical documentation, refreshed on the same cycle as the code
- The changelog, security fixes included
- Functional documentation, with screenshots from the current version
- A fifth proof we do not produce ourselves: the interface recently gained Italian, Persian and Albanian, contributed from outside the team
What changed in one quarter?
The process is a quarter old, and the direction is clearer from the comparison than from the current state.
In June
Every stage was started by a person, separately.
Nothing remained after implementation except the agent’s assurance that it would work.
A developer opened a browser and described each error to the agent in words.
Code review was manual, and decisions from planning stayed in chat.
Today
An orchestrator keeps the stages in order.
The agent tests itself and reports what it could not cover.
Code review starts automatically.
Decisions go back into the issue, where they can be read months later.
What comes next?
The nearest goal is long HR processes – tests that can bring the system to a state where offboarding or a change of employment terms can be checked. In parallel we are measuring which stages cost the most, so we know what to optimise first. And we are running the next artefact review; the previous one produced one concrete fix to the instructions, so we expect more.
Frequently asked questions
Does an AI agent push changes to MintHCM on its own?
No. A developer approves the plan, a senior engineer reviews the code, a tester confirms it works. A change reaches the main branch only after all three decisions.
Who is responsible for code written by an agent?
The team. The developer for the plan and implementation, the senior engineer for code review, the tester for acceptance. The agent is a tool, not an accountable party.
Does my data go to an AI model?
No. This process concerns the development of MintHCM itself, not your instance. The agent works on code and test environments.
Do AI-written tests replace a tester?
No. The tester checks what the test plan is missing, adds cases and clicks through the rest by hand. A person signs off.
Which agent do you use?
Claude Code from Anthropic, extended with our own implementation instructions and an orchestrator that carries a task through the stages.
Did agents replace people on your team?
No. The starting point changed: instead of writing code from scratch, the team reviews plans, reads reports and decides. With a share of the agent’s decisions still needing correction, the process is hard to imagine without people.
You do not have to take our word for it
We have described the process, given the numbers and said what the agent cannot do. Every one of those sentences can be checked – in the repository, in the changelog and in the documentation.