Vibe coding for HR after the hype.

Software building keeps getting easier.

OpenAI just released GPT-6.1 Sol with a focus on coding, computer use and professional work.¹ xAI recently opened Grok Build to every plan, letting people describe an app and get a working version directly inside Grok.² Grok Bot goes further and gives AI agents their own computers to work across apps and tools.³

For HR, this changes what is practical.

A small internal HR app can now go from an idea to a working first version in hours or days. Many small ideas no longer need to wait for a full software project or a place on a long IT roadmap.

That opens a lot of interesting doors. A policy comparison tool. A survey analyzer. A compensation planner. An onboarding tool.

The build is getting dramatically easier.

The question is what happens after it works.

For some tools, both phases stay light.

A survey analyzer can take an uploaded file, find the main themes and give HR a summary to review. It can stay read-only. It does not need to change an employee record. If it is unavailable for an hour, very little happens.

Other tools need much more around them. Once people depend on them, someone has to control access, keep the data correct, maintain connections to other systems, update the software when the process changes and deal with failures.

That work can continue for years after the first version was built.

Some use cases should stop earlier

Before looking at lifecycle cost and effort, I would first decide whether the use case is a sensible custom build at all.

• Does it become a core system of record? Payroll, HRIS and benefits enrollment carry responsibilities that go far beyond the interface.
• Does it make an important employment decision? Hiring, pay, promotion, discipline and termination need a much higher bar than drafting, analysis or preparation.
• Can a mistake materially affect an employee before a human catches it? The harder the action is to reverse, the more important human review becomes.
• Is the difficult part outside the code? Licensed data, payment systems, external talent databases and other infrastructure may be better left with an established provider.

These do not always mean “do not build.”

Sometimes the better answer is a smaller custom layer on top of an existing system. Sometimes AI should prepare the work while a person or established system keeps control of the final action.

Then look at what you will own

If the use case still looks good, I would look at five things before moving from prototype to real internal software.

This is where two tools that look equally easy to prototype become very different software decisions.

A payroll engine has to get every paycheck right. It handles highly sensitive data, creates official records, depends on changing rules and has to work when payroll closes.

The survey analyzer carries far less responsibility after launch.

Vibe coding gives HR many more ideas worth testing.

For anything people will depend on, include the full software lifecycle in the decision.

Best,
Henry Kaerki
Founder, Wellhana