Vibe coding lets non-engineers write down the operational logic that's been stuck in their heads[1].
I was in San Francisco last week and sat down with an HR team that had vibe coded their own performance review tool. They built a system where the AI and the manager submitted reviews independently, then forced a conversation on the gap. It was mature and in daily use.
Performance is one of the clearest expressions of how an organization actually operates. And yet most organizations are unhappy with both their process and the tools they use for it. This team didn’t want a generic system — they built one that matched their model.
We saw the same pattern at Pyn when our Customer Success team shipped their first PRs: people closest to the problem, building the solution directly.
A hiring rubric, an onboarding checklist, a performance calibration: all of it is operational logic, and always has been. Even the decision to approve a minor employee expense reflects the culture of your organization. The decisions a company makes about its people are the operational model of the company. The difference is that the people who own them can now write them.
Most people systems today live in a scattered mess: policies in Google Docs, processes in Confluence, onboarding flows in version 3 of a Notion wiki, comp bands in a spreadsheet. Your HRIS grew out of payroll, and it shows[2]. Employees route around it. Managers build their own onboarding, completely independent of the centralized one. The official email says show up at 9am; your manager emails you directly -- let's meet for a coffee at 10. The first hour of day 1 sets the tone, and already nobody is following the process.
Some of this friction is essential. People decisions should involve judgment and conversation. But most of it is accidental: bad tooling, scattered information, poor visibility, and processes that live in someone's head.
Software teams recognized the same problem decades ago and solved it with version control. Every change tracked, reviewed, and reversible. People teams, responsible for some of the highest-stakes decisions in any organization, are stuck emailing Word documents back and forth.
The faster horse problem
For more than a decade I worked in large financial institutions. In these companies, performance reviews can bring entire departments to a standstill for weeks. For large parts of this time I worked as a contractor or a consultant, which excused me from it. And ironically I was considered a lot more productive as a result.
I've written before about faster horses in AI productivity. Performance reviews are the canonical example: managers are using AI to generate reviews, HR gets a mountain of content and uses AI to summarize them. The underlying process is untouched: a manager generates a review that nobody reads carefully, which feeds a calibration that's often theater, which produces a rating that may have been clear from the get-go. The manager then has the job of justifying this rating to the employee, who probably should have gotten more direct feedback long ago.
More generated content with the same or worse outcome. The true productivity unlock is getting the performance signal directly.
The team I met in SF hadn't built a faster horse. They'd rebuilt the process itself. Their tool didn't generate review text. It structured the inputs: clear criteria, evidence linked to actual work, calibration against the rubric. The review conversation could focus on judgment instead of paperwork. The AI gathered the necessary signals and produced an initial assessment. Without seeing this, the manager submitted theirs independently. The AI never overruled the manager, but when there was a delta you could ask "what are we missing?" You focus on the outliers rather than the rote. The AI handled the inputs and the manager still owned the verdict.
What I mean by "codebase"
A codebase is just a shared set of files that defines how something works. Software teams edit it collaboratively, track every change, and use it to drive automation. When I talk about People Systems, I mean an actual codebase. People processes can be encoded, versioned, and executed in the same way. Not every part of them can or should be. But enough of them can that the model starts to hold.
What this looks like in practice is a folder of documentation, skills, scripts, and integrations — with full track-changes — that's actively directing AI agents and that the whole team can edit.
There's a trend emerging where operational models are expressed as repositories: agent skills, scripts, and structured documentation sitting in git -- the version control system that powers most software codebases[3]. But most of these tools focus on personal productivity. The more interesting application is in processes that involve multiple people making coordinated decisions, which is exactly what people systems are.
Think about what an interview debrief actually is. Strip away the meeting and the gut calls and you're left with: calibration data, a rubric, scoring logic, synthesis of multiple signals into a decision, which is a pipeline[4]. A promotion process is criteria applied to evidence with thresholds and logic. Some of these things can be expressed with agentic code now. They just never have been, because the tooling didn't exist.
Why now
Three reasons.
LLMs can work with unstructured input. People systems have always been unstructured and cross-functional, which is exactly where traditional software failed. Interview feedback is freeform text. Performance evidence is scattered across PRs, Slack messages, docs, and one-on-ones. Previously, you needed people to synthesize all of this because no software could handle the ambiguity. LLMs can. Well enough to do the first pass that used to take hours[5].
Internal users are the fastest feedback loop. Teams succeeding with AI are the ones with tight feedback loops. Internal people systems have the tightest loop possible. Your users are in the same Slack workspace. You can ship a change at 2pm and know by 3pm whether it worked. This is the opposite of shipping enterprise software into a black hole.
The problem is the connective tissue. Your ATS has structured candidate data. Your HRIS has employee records. The data exists but doesn't connect. The mess lives in the spaces between these systems: the handoffs, the interpretations, the "ask Mark because he knows how this works." Agents are good at that glue work: moving between structured systems using unstructured context.
What this actually looks like
Some version of this is already happening at companies I've spoken with in the last few months.
-
Interview synthesis. One company replaced their debrief meeting entirely. Interviewers submit structured feedback against a rubric defined in a shared config. An agent synthesizes the signals, flags disagreements, and produces a recommendation with cited evidence. The hiring manager still makes the call, but the recruiter who used to spend two hours compiling a brief now spends fifteen minutes reviewing one.
-
Onboarding as a workflow engine. Instead of a checklist in Notion that nobody follows after week one, an agent walks new hires through their first weeks. Provisioning access, scheduling introductions, surfacing relevant documentation at the right moment, escalating blockers to the manager. The key difference from a traditional automation: the agent adapts. The onboarding "program" is a codebase that gets better with every new hire[6].
-
Compensation analysis. At one company, the annual comp review used to take their People team six weeks. Managers submitted requests into a spreadsheet. People partners manually reconciled against bands, budgets, and equity targets. Now an agent does the first pass: flagging outliers, surfacing pay gaps across demographic groups, producing a draft recommendation with its reasoning visible. Six weeks became three days.
-
Performance signals. Poor performance is often temporary, but it compounds fast when unaddressed. One struggling team member can drag down the engagement of the whole team. The problem is that signals arrive in fragments: missed one-on-ones, declining participation, disengagement. By the time it surfaces in a formal review, the damage is done. An agent can synthesize those signals early and flag them to the manager. This is also the example most likely to make employees uncomfortable, and rightly so. The line between supportive early warning and automated surveillance is entirely in how it's implemented. Catch it early and it's a conversation. Catch it late and it's a PIP.
The question to ask about any of these: is the current friction accidental or essential? If a manager and a People partner need to sit together and talk through a difficult situation, no agent should be in the middle of that. If they're spending three hours compiling the documentation before that conversation, that's accidental friction worth eliminating.
Once these processes are expressed as code, they get all the infrastructure that software teams take for granted: version control, code review, rollbacks. When someone asks "why did we change the interview rubric?" you get a commit message and a diff instead of "I think Anne did." Companies struggle with process consistency because the processes live in oral tradition and half-maintained wikis. Treat them as a codebase and the problem starts to dissolve.
The catch(es)
Not everything needs an agent. A specific email needs to go to a new hire at 10am on their first day? That's an automation. It should happen the same way, every time. AI is probabilistic by design. It won't do the same thing every single time. If you don't want or need variation, don't hand it to an AI. I wrote about this distinction in Adaptive, not Compliance[7]. Automations are reliable and cheap.
The model-as-code idea is only as good as the humans reviewing the commits. Interview rubrics already encode bias. Promotion criteria already favor certain working styles. Compensation bands already reflect historical inequities. Putting these into code doesn't fix any of that. What it does do is make it visible. A rubric in someone's head is invisible and unreviewable. A rubric in a config file can be diffed, audited, and challenged. The tooling only makes them visible. Making them right is the job of the people reviewing the code, and the stakes are people's careers.
There's also a risk of over-engineering. Not every people process needs to be a pipeline. Sometimes the right answer is a conversation between two humans. The accidental-vs-essential question applies here too: if the friction is the conversation itself, adding technology makes it worse, not better.
Where this goes
I've spent the last few months writing about how engineering teams need to change their processes for the AI era. The same logic applies to every operational function in a company. But People teams might be the most interesting place to start. People processes touch every employee and are already full of the kind of judgment calls LLMs handle well.
This changes what it means to work in People. The best People teams I've worked with already think like operators and systems thinkers, not administrators. What's changed is that they no longer need to wait for an engineer to translate their ideas into software. The People partner who understands why your onboarding is failing can now fix it directly. The recruiter who knows the interview rubric is broken can rewrite it, commit it, and ship it. They can fix what they can see is broken[8].
The team I met in SF wasn't waiting for a vendor to build them a better HR tool. They built it themselves. The people closest to the process are now writing the process, in code.