Imagine an HR professional has an idea on Tuesday morning and by Tuesday afternoon, they have built a working app.

There was no development team, no six-month project plan, and no long requirements document.

They described what they wanted to an AI coding tool, refined it through conversation, tested a few things, and suddenly they have an application that solves a real HR problem.

Pretty amazing, right?

Now fast-forward six months.

The app has 300 users. It contains employee information and three HR processes depend on it. AND, the person who created it has left the company.

And one Monday morning, it stops working.

Who owns it now?

That may become one of the most important questions HR and IT need to answer as vibe coding spreads through the workplace.

Vibe coding allows someone to describe an application in natural language while AI generates much of the underlying code.

That dramatically lowers the barrier to creating software.

An HR professional who would never call themselves a programmer might create an onboarding tracker, manager coaching tool, interview-question generator, internal skills directory, workforce planning dashboard, or employee FAQ application.

That opens up some exciting possibilities.

The people closest to the problem can suddenly experiment with solutions themselves.

But there is an important distinction we need to make.

Being able to build an app does not automatically mean being prepared to operate one.

Security organizations are already warning that AI-generated applications can move outside normal technology governance, sometimes without security reviews, dependency checks, proper authentication, or clear ownership.

That is where HR and IT need each other.

HR brings something incredibly valuable to vibe coding.

We know where employees get frustrated, which spreadsheets have become monsters, which processes require too many handoffs, and which tasks make everyone ask, “Why are we still doing this manually?”

They understand architecture, authentication, integrations, cybersecurity, data storage, backups, monitoring, testing, dependencies, scalability, and what happens when something breaks at 8:03 Monday morning.

Neither side has the complete answer by itself.

That makes vibe coding a great opportunity to change the relationship between HR and IT.

Instead of HR saying, “Build this for us,” the conversation can become, “We built something that appears useful. Help us determine whether and how it should become part of the business.”

That is a much more interesting partnership.

Here is where things can sneak up on us.

You build something for yourself.

Then you show it to a coworker.

They love it.

Your manager asks for access.

Someone sends it to another department.

Suddenly your little experiment has become an application people rely on.

Congratulations.

Your prototype just got promoted.

And promotions come with additional responsibilities.

Enterprise guidance around vibe-coded software increasingly points to the same issue. An application that works is not automatically ready for production use, particularly when it connects to sensitive information, identity systems, internal databases, or other business applications.

This is the moment when HR and IT should have a defined process.

Not every vibe-coded app needs the same level of oversight.

A personal calculator you created to experiment with workforce scenarios is very different from an application used by 2,000 employees to access benefits information.

HR and IT could create three simple categories.

🟢 Personal Experiment

Used by one person or a small test group with synthetic or nonsensitive information.

The creator can continue experimenting within established AI and technology guidelines.

🟡 Team Tool

Used repeatedly by a department or team and beginning to influence actual work.

IT should know it exists, and HR and IT should jointly review data, access, dependencies, documentation, and support needs.

🔴 Business Application

Used in an operational process, accessed broadly, connected to company systems, or handling sensitive data.

At this point, it needs to enter the organization's normal technology lifecycle with appropriate security, testing, ownership, support, and governance.

The labels can be different.

The important part is recognizing when an experiment becomes infrastructure.

Here is a question I would require before any vibe-coded HR application moves beyond experimentation.

Who owns this if the person who created it disappears tomorrow?

There should probably be two answers.

This person owns the purpose of the application.

They answer questions such as:

HR should not hand those decisions to IT.

Technology cannot decide what the HR process should be.

This person or team owns the health of the application.

They understand:

That technical owner does not necessarily need to have written the original app.

They do need enough visibility and documentation to support it.

This matters because maintainability has emerged as one of the major enterprise concerns around vibe coding. AI can generate working code quickly, but unclear ownership, inconsistent architecture, dependencies, and technical debt can make applications increasingly difficult to support as they grow.

You probably do not need a 40-page technical specification for every small application.

But you should capture enough information that someone else can figure out what you created.

I would create what I call an App Birth Certificate.

Every HR-created application moving into regular use would record:

That last one matters more than it might seem.

Software should not live forever merely because nobody remembered to turn it off.

Here is another good governance question.

What happens if this breaks?

If the answer is, “Paul has to fix it,” you do not have a maintenance strategy.

You have Paul.

And Paul may be on vacation.

Or promoted.

Or retired.

Or simply staring at the AI-generated code thinking, “I have absolutely no idea what any of this means.”

That is the hidden risk of vibe coding.

AI can help someone create software beyond their technical understanding.

That is wonderful for experimentation.

It becomes dangerous when the organization depends on software that nobody understands well enough to maintain.

Before an application becomes operational, HR and IT should agree on a few things.

Who monitors it?

Someone needs to know when the application fails instead of waiting for an employee to submit a help-desk ticket.

Who updates it?

Browsers change. APIs change. AI models change. Authentication requirements change. Integrations change.

The app that works today may not continue working indefinitely.

Who tests changes?

The most dangerous sentence in vibe coding may eventually become, “I asked AI to fix it and now it works.”

Great.

What else did it change?

AI-generated software still needs version control, testing, documentation, and rollback options so that a fix does not quietly create another problem.

Who handles security updates?

AI-generated applications can introduce vulnerabilities, insecure permissions, exposed credentials, or weak access controls if security is not intentionally designed and reviewed.

Who supports the users?

If employees depend on the app, somebody needs to answer their questions.

“Ask the person who vibe-coded it” is not a scalable support model.

There is another challenge coming.

HR may not build one application.

Your organization may eventually have dozens or hundreds of employee-created apps.

That can create a new form of shadow IT.

Except this time, instead of employees secretly subscribing to software, they are secretly creating it.

Organizations should consider maintaining a simple registry of employee-created applications that move beyond personal experimentation.

You want to know what exists.

You cannot govern software nobody knows exists.

This is where organizations can easily overcorrect.

IT sees the risks and creates a process so restrictive that employees stop building anything.

That would be a mistake.

The ability for an HR professional to say, “I have an idea,” and create a working prototype that afternoon is incredibly valuable.

You want that experimentation.

The goal should be to create a clear path from experiment to enterprise.

Experiment freely within defined boundaries.

Show what works.

Test the value.

Then, when people begin depending on it, increase the level of technical rigor.

Recent enterprise guidance makes essentially this distinction. Vibe coding can work in business environments when rapid creation is surrounded by appropriate review, security, testing, deployment controls, and lifecycle governance.

That approach protects innovation instead of suffocating it.

I would love to see HR and IT establish a simple agreement.

HR owns the problem.

HR can prototype the idea.

IT helps establish the boundaries.

HR validates the business value.

IT evaluates the technical risk.

Together they decide whether the prototype should become an operational application.

Then they assign business ownership, technical ownership, support expectations, security requirements, and a review schedule.

That is a much healthier model than throwing every HR technology idea over the wall to IT.

It is also healthier than HR building production software without IT knowing it exists.

This discussion is bigger than apps.

Vibe coding demonstrates where AI is taking us.

Employees increasingly have the ability to create capabilities, not merely use capabilities someone else provides.

That changes the skill requirements for the workforce.

People need enough AIQ Fluency to understand what AI can help them create.

They also need judgment to recognize when their creation has crossed into an area requiring expertise they do not have.

That is an important distinction.

AI empowerment should increase human responsibility, not reduce it.

This is one reason my AIQ Advantage™ work focuses on developing the capability to direct, evaluate, and work with AI rather than simply teaching people which buttons to push.

We want employees experimenting.

We also want them recognizing the moment when they need to say, “This works. Now I need someone else at the table.”

The HR professionals of tomorrow may not simply select HR technology.

They may create portions of it.

That makes AI fluency, business-process knowledge, risk awareness, and collaboration with IT increasingly connected skills.

Some of the best vibe-coded applications may originate with people experiencing the problem every day.

HR should encourage that creativity.

Our responsibility is to help turn good ideas into responsible solutions rather than assuming every technology solution needs to originate inside IT.

Vibe coding will not remain an HR issue.

Finance, marketing, operations, sales, and other functions will build applications too.

HR can help the organization define expectations around capability, accountability, training, role responsibilities, and appropriate experimentation.

An application that saves 500 hours this year but becomes an unsupported operational problem next year may not have generated the return everyone thought it did.

A true AIQ Return on Intelligence™ should consider the complete lifecycle.

Those questions belong together.

You cannot fully understand the opportunity of vibe coding by watching someone demonstrate it.

Try building something.

Create a simple interview-question app. Build a manager coaching assistant. Create a tool that helps someone explore career paths. Use only synthetic information while you experiment.

You will quickly experience something important.

The moment the thing works, your brain starts imagining what else you could build.

That experience helps HR understand why employees across the organization are going to embrace these tools.

It also helps you understand why governance cannot simply consist of telling everyone to stop.

HR needs enough firsthand experience to help create an environment where employees can experiment safely, recognize boundaries, collaborate with technical experts, and turn the best ideas into sustainable business capabilities.

That is a much stronger role for HR than standing on the sidelines handing out rules.

Building the app is only the beginning.
Every operational application eventually needs ownership, security, testing, maintenance, support, and a retirement plan.

HR and IT bring different expertise to the same problem.
HR should own the business need while IT helps make sure the technology can survive beyond the prototype.

Governance should create a path forward.
Give employees room to experiment, then increase oversight as an application moves from personal idea to business dependency.

Go build something.

Seriously.

Experiment with what AI can help you create.

But when someone looks at your prototype and says, “Can we roll this out to everyone?”, resist the temptation to immediately say yes.

That is your signal to invite IT into the conversation.

Ask who will own it, maintain it, secure it, test it, support it, and eventually retire it.

Because the real win with vibe coding is not creating an app in an afternoon.

It is creating something useful enough to last without leaving everyone stranded when the vibe wears off.

Here is a ready-to-use prompt you can use to create governance for a vibe-coded app:

ROLE:

You are an HR technology governance advisor with experience in AI adoption, HR operations, information security, change management, and cross-functional work with IT.

You help organizations evaluate employee-built and vibe-coded applications so useful ideas can move forward without creating unnecessary security, maintenance, support, or ownership risks.

REQUEST:

Help me evaluate and manage a vibe-coded HR application from initial prototype through possible business use.

Use the information I provide to determine what HR should own, what IT should review, what risks need attention, and what must be in place before the app is used more broadly.

GOAL:

Create a practical decision and governance plan that helps us preserve the value of the app while making sure someone can maintain, secure, support, update, and eventually retire it.

The plan should help HR and IT decide whether the app should remain an experiment, become a team tool, or move into formal business use.

INSTRUCTIONS:

OUTPUT FORMAT:

Provide the response using these sections:

APP PURPOSE: [Describe what the app does and the HR problem it solves]

CURRENT USERS: [Who is using it now and how many people]

PLANNED USERS: [Who may use it in the future]

DATA USED: [Describe the information the app accesses, stores, or processes]

SYSTEM CONNECTIONS: [List any HRIS, ATS, payroll, file storage, API, or other integrations]

WHERE IT IS HOSTED: [Insert platform or environment]

WHO BUILT IT: [Insert role or team]

CURRENT BUSINESS OWNER: [Insert person or role if known]

CURRENT TECHNICAL OWNER: [Insert person or team if known]

KNOWN RISKS OR CONCERNS: [Insert security, privacy, reliability, support, compliance, or maintenance concerns]

CURRENT DOCUMENTATION: [Describe what exists today]

BUSINESS DEPENDENCY: [Describe what would happen if the app stopped working tomorrow]

Using AI doesn’t have to be all work. Here is a fun way to interact with AI.

ROLE:
You are a creative writing assistant who specializes in crafting light, engaging poems. You understand how to adapt tone, voice, and personality to match the unique traits of an individual’s pet.

REQUEST:
Write a short poem from my pet’s perspective that reflects their personality, habits, and the relationship we share. Use the details under ###PetProfile to shape the style, tone, and emotional framing.

GOAL:
Create a poem that:

Captures my pet’s voice authentically.

Reflects how they might see me and our daily interactions.

Uses simple, clear language suitable for sharing with a team or using in a wellness or engagement activity.

INSTRUCTIONS:

Use the pet description under ###PetProfile to determine the mood (e.g., playful, loyal, dramatic, calm).

Include 6–10 lines written in first person from the pet’s point of view.

Avoid overly sentimental or overly comedic wording; keep it warm, light, and relatable.

Add one line that subtly highlights why pets can positively influence wellbeing or morale.

Offer an optional closing suggestion for how this poem could be used as an employee engagement or team-building activity.

OUTPUT FORMAT:

Pet Overview: Brief summary of how you interpreted the pet’s personality.

Poem: 6–10 lines written from the pet’s perspective.

Engagement Idea: One practical way to use this poem in a team or HR setting.

###PetProfile:
Pet Name & Type: [Insert pet name, species, and breed]
Personality Traits: [Insert temperament, behaviors, or quirks]
Favorite Activities: [Insert routines, toys, or habits]
Relationship Notes: [Insert how the pet interacts with you or others]