The interesting thing about vibe coding isn't that it helps engineers write code faster. It's that it lets non-engineers express operational logic that's been trapped 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. This wasn't a scrappy solution — it was mature and fully operational.
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.
Your hiring rubric is business logic. Your onboarding checklist is a workflow. Your performance calibration is a decision tree. These have always been operational logic. 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. Compensation 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 wasn't doing the review. It was making the review worth having.
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 don't mean "codebase" metaphorically here. I mean it literally. 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. That's 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 things have converged to make this possible.
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 connective tissue is the problem, not the data. Your ATS has structured candidate data. Your HRIS has employee records. The data exists, but it stubbornly 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." That connective tissue is exactly what agents are good at: navigating between structured systems using unstructured context.
What this actually looks like
I'm not speculating. 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 of data wrangling became three days of actual human judgment calls.
-
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. But caught in weeks, it's a course-correcting conversation. Caught in quarters, 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?" the answer isn't "I think Anne did." It's a commit message with a diff. The reason companies struggle with process consistency isn't that their people are bad at following processes. It's that the processes live in oral tradition and half-maintained wikis. Treat them as a codebase and the problem starts to dissolve.
The catch(es)
There are three things to be careful about.
First, 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.
Second, 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 makes processes transparent. It doesn't make them right. That's the job of the people reviewing the code, and the stakes are people's careers.
Third, there's a real 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. Not because HR is broken, but because people processes touch every employee and are already full of the kind of judgment calls that LLMs are surprisingly good at supporting.
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. The gap between "knowing what's wrong" and "fixing it" collapses[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. Not in docs, not in meetings. In code.