How AI Is Changing Product Development in HR Tech

If you spend enough time talking to people in product and technology over coffee, at an event, or after a particularly long sprint, the same subjects keep coming up. Everybody once was or still is dealing with a legacy system nobody wants to touch. We all had a requirement that meant one thing to Product and another to Engineering. A roadmap moving faster than the platform can safely evolve. And, somewhere in the middle of it all, there´s a tired team trying to work around decisions that were never really documented.

That is not just coffee-chat tales. Technical debt, incomplete requirements and misaligned expectations between product and engineering are long-running constraints on software teams’ ability to ship and evolve. A multi-country study of 653 practitioners found technical debt across design, testing, code, architecture and documentation; delivery delays, low maintainability and rework were among the effects most often reported. 1

At SideUp, we hit that reality at a critical moment. Our previous application had limitations in quality, speed, capacity and technical debt. When it could not support a new product need related to payments, the cost of moving forward became impossible to ignore, but the pressure was higher than ever.

We didn’t give into the useless temptation of asking an AI tool “build me the perfect product.” Instead we aimed to answer a question that surfaced often in our dreamy small talks: could we make the product context, technical boundaries and quality expectations clear enough for people and AI agents to build together with more confidence?

I never believed AI would create that discipline by itself, fix an absent methodology, a disorganised way of working, undocumented decisions or unclear accountability. Best case, would make it more visible, and worse case, would dive deeper in this kind of chaos in a pace no human can catch.

What followed changed how we work. A four-day experiment, covering the complete process after a Stitch concept, became a full delivery pipeline operated by one product team, with complementary Product, Engineering, QA and DevOps specializations. Later, our relatively small team built a new application from scratch in few months, one we assess as more robust and higher quality than the previous application built through traditional methods.

Quick summary: what you will learn

In this guide, I will share:

• Why AI product development in HR tech is really a product-system and operating-model question, not only a tooling question;

• Why a polished, clickable prototype is not the same thing as a real product;

• How SideUp used product narratives, API contracts, open questions and small delivery slices to work with agents;

• How one product team can bring together Product, Engineering, QA and DevOps expertise around the same customer outcome; and

• What we learned about keeping AI fast without making the product fragile.

The problems AI does not magically fix

A legacy platform can make a team feel slow even when everyone is working on the edge. Most people in technology know the feeling: the simple request that takes three weeks because it touches four old decisions, two integrations and a part of the codebase nobody has felt safe changing for years.

But the terrifying platform is the outcome, not the root problem. When the way of working is fragmented, there is no shared methodology, ownership is fuzzy, decisions live in people’s heads and priorities are hard to see, the problem is bigger than the code, and no one knows what “done” actually means.

Research calls it requirements engineering debt. It can grow when scope, stakeholder understanding, requirements or documentation are incomplete, ambiguous or poorly managed. The practical consequences are familiar: delivery delays, rework, lower external quality and lower maintainability. 2

For HR Tech, that matters even more. We are not building a feature in a vacuum. A product may have to make benefits rules, eligibility, payments, partner integrations, permissions, employee experience and administration work together. If we are unclear about the product intent or hide technical limits until late in the process, the impact is not only internal. It reaches HR teams and employees who need the platform to work.

Learning where AI is brilliant and where it is not enough

There are three things I believe everybody must learn: knowing what you know, knowing what you do not know, and never confusing the two things. I knew I could not deliver a production-ready application alone. My goal was prototyping and validating a product hypothesis and product pipeline, which is what I know how to do.

The first experiment was build a new backoffice. Most product development time was naturally pulled toward customer-facing work, leaving customer support team with apiece of solution that was incomplete, hard to evolve, and never a priority. But to enhance experience, we had to provide more autonomy and visibility for our customer success team.

I started in Stitch. I am not a cloud-development or DevOps specialist, although I do have a foundational understanding of logic. That was enough to help me explore, ask better questions, structure the problem and test AI toolset capabilities; it did not replace the product team’s engineering, QA or DevOps expertise.

Stitch gave me the first concept in a few hours, and I fed it to Google AI Studio to evolve the initial idea into an interactive prototype by the end of the first day. It was exciting: people could actually click through it, react to flows and tell us what felt right, what felt confusing and what they needed next. That immediately made our conversations with users better. We could talk about mechanics, usability and real workflows rather than asking them to imagine a solution from a document or weeks of prototyping and connecting interactions in traditional mockups.

But that was not a product yet: it had been created empirically, piling up thoughts and hopes through the iterations the tools gave back to me. It did not yet carry enough structured context or product logic consistency challenge to guarantee that every business rule, architecture decision, integration or exception had been considered. The output looked convincingbut was far from being dependable.

It turns out that this is a wider concern, not just something I felt during our experiment. In a 2026 survey of 1,149 technology professionals, 96% did not fully trust AI-generated code to be functionally correct, and 95% said they spend at least some time reviewing, testing or correcting AI output.3

That was one of our biggest lessons: AI can give you something plausible before it gives you something ready. It can accelerate a strong method, but it cannot replace one.

The turning point: context

Once the one-day-made interactive prototype started giving us user feedback, the question became: how do we turn this into something we can really build?

Instead of a nice and clever prompt, the decision was bringing the practices we were already building into SideUp’s culture into the way we worked with AI: teaching agents how we work at SideUp before anything else.

We used Working Backwards to start with the customer problem and the intended product outcome. We used Team Topologies to think carefully about service boundaries and the fracture planes behind our microservice design. We used Contract First so API contracts and domain requirements would set technical boundaries before implementation. And we brought Scrum-style refinement into agent-supported work. In the first two hours of the second day, Claude Code learned how to work for SideUp supporting the weapons of our choice to deliver an incredible experience.

The principle was simple: if we ask an agent to build something, the agent should not have to decide what the product is supposed to be or how to organize the workload.

The rule we kept coming back to

A slice was not ready because an agent could generate code for it. It was ready when the product requirements were met and there were no open questions left.

That distinction sounds straightforward, but it changed a lot. It forced us to separate an interesting idea from a decision the team could safely implement. It gave agents a much healthier role: help us analyse completeness, break work down, reveal gaps, plan options and execute within boundaries we had agreed together.

This also lines up with DORA’s 2025 research on AI-assisted software development. DORA’s conclusion is that AI amplifies the strengths and weaknesses already present in an organisation. Its AI Capabilities Model points to user focus, strong version control, AI-accessible internal data, small batches, a clear AI stance and a quality internal platform as the conditions that help AI adoption create better organisational performance.4

In other words: the tools matter. The system around the tools matters more.

Four days that changed the conversation

By the end of the second day , the initial Stitch concept had become an interactive prototype, a product narrative, detailedAPI contracts and domain requirements, written by agents, validated by human. I then used Claude Code to look at whether those artefacts were complete, plan the infrastructure and organise the development work.

I worked with separate agents in VS Code, each with a specific responsibility: one helped refine the backlog with me, another looked at UI, another looked at backend needs... I would refine a piece of work with the first agent until it was genuinely mature, then hand it to the agent best placed to create what we needed: an entire UI, reusable components or a microservice. Third and fourth days were intense and insane: the pace was fast and the result accurate to collect insights on how to move faster with AI.

The agents also generated API documentation and an Azure developer portal. I ran each delivery locally. After four functionalities were ready, I deployed them into a development environment and checked that they worked as one integrated application.

Across the four days since the initial Stitch concept, the experiment moved from product narrative and interactive prototyping through refinement, specification, planning, development and validation. It produced a functioning backoffice in a development environment, with an interface, infrastructure, authentication, a small backend, API health checks, customer creation and the ability to check transactions with a banking partner. It was a meaningful proof of what we could validate and build next—not a claim that I had delivered a production-ready application alone.

“Starting just after the initial Stitch concept, four days were enough to prove that an individual could turn disciplined product context into a working system. The real test began after that: turning a solo experiment into a delivery pipeline that one product team could own, improve and scale.”

That is an important distinction. The goal was never to show that one person could replace a team. It was to find out whether a disciplined process and specialised agents could give the product team a better way to build together.

The real test: making it work with one product team

The experiment proved that the approach was possible. The real transformation started when it became shared, traceable and repeatable.

At SideUp, Product, Engineering, QA and DevOps are not separate teams passing work along a departmental chain. They are complementary specialisations within one product team. We build the product together, with customer obsession as the reference point. Software is not the end in itself; it is one of the ways we solve a real customer problem, create value and deliver the experience we have promised.

So the pipeline now works through one unified product team. Product direction, implementation, quality and infrastructure are distinct areas of expertise, but they stay connected to the same customer outcome and shared product responsibility. Agents can speed up analysis, planning, execution and validation. They do not remove accountability, and they should not fragment ownership.

One product source of truth, not a pile of tickets

Our product narratives, requirements, acceptance criteria and API contracts live in a dedicated Git repository. That is our product source of truth. It means the context agents receive is versioned, shared and connected to the decisions that created it.

Within Product Ownership, we break the work into slices and prioritise it. An MCP integration of Claude Code with Asana keeps priorities and progress synchronised, which gives people visibility without spending hours searching for, dragging or manually updating tickets.

For people applying engineering expertise within the product team, this makes the work much more straightforward. They can see what needs to happen, in what order and against which product expectations. We are not giving an agent an empty instruction to “build a feature.” We are giving the team a version-controlled product source of truth, then letting each specialist use agents inside it.

QA and DevOps are how we keep speed from becoming fragility

The DevOps specialisation starts from the same product inputs and defines architecture within SideUp’s infrastructure strategy. Infrastructure is planned deliberately. An infrastructure design brief is validated at executive level before implementation, then followed by detailed planning and verification. Agents help us compare cost implications, evaluate infrastructure options for each scenario and surface possible vulnerabilities or other points of attention before implementation.

The QA specialisation keeps quality visible. Together, the product team validates delivery against product requirements and governance criteria, with end-to-end automated tests, regression, test scenarios and coverage. This is what stops AI-assisted speed from turning into unverified complexity.

That human responsibility is not a limitation of AI. It is the reason it becomes useful. A 2025 study of technical-debt-management tooling found that practitioners want to retain control over tool execution and results, reinforcing the case for human-centred automation rather than fully delegated decisions.5

What changed for SideUp: more capacity, not fewer people

The full pipeline is now running with the team. In our experience, people are working with more autonomy and speed, while delivering more efficiently and more precisely against product needs and company direction.

The clearest outcome is the new application itself. A relatively small team built it from scratch in three months. In our internal assessment, it is more robust and higher quality than a constrained legacy application that took more than three years to build through traditional methods.

That is not a controlled industry benchmark, and I would not present it as a promise that AI will do the same thing everywhere. It is a SideUp case study. What matters is how we got there: we did not become faster by removing product work, governance or quality assurance. We became more capable by making those things clearer, versioned, shareable and usable by people and agents.

Expert insight: the bottleneck has moved

Here is how I would frame the real question for any HR Tech leader thinking about AI: it is not whether one person can generate a convincing screen or a working code sample. We already know that can happen. The question is whether your organisation can repeatedly turn customer insight into a product increment that is governed, testable and ready to operate.

That shifts the investment toward things that may feel less glamorous: a product source of truth, explicit contracts, believable acceptance criteria, small batches, visible priorities, deliberate infrastructure and quality verification. These are not the slow part around AI. They are the part that turns AI-enabled activity into real product capacity instead of more rework later.

For a growing HR Tech business, this matters a great deal. Faster feature generation without clear integration and governance can make an already complex benefits platform even harder to evolve. Faster learning, smaller validated slices and clearer collaboration can give a small team the capacity to respond to customers without losing control of quality.

The communication lesson

Our agents consistently found places where a requirement was not deep enough or a decision had not yet been made. Sometimes they misunderstood a direction. But people do that too. Ambiguity is a communication problem before it is an AI problem.

For us, that made communication more important, not less. The quality of AI-assisted development depends on how clearly a product team can explain customer context, constraints, rules, definitions of done and exceptions. Better prompts help. Better shared understanding helps much more.

A practical checklist for AI product development in HR Tech

If you are beginning this journey, these are the questions I would ask before expecting agents to make your product team faster.

Frequently asked questions

Is AI product development in HR Tech mainly about writing code faster?

Not really. Code generation can speed up some activities, but the bigger opportunity is improving the path from a real customer problem to a validated delivery. In HR Tech, that path includes business rules, integrations, employee experience, security and administration. AI helps most when the product context, technical constraints and quality expectations are already clear. The goal is not more code. It is a more reliable way to build the right product.

What is the biggest risk of vibe coding in a product team?

The biggest risk is confusing a plausible prototype, or a working local demo, with a production-ready solution. Knowing that distinction is a form of product maturity. Something can look complete while still missing integration design, exception handling, security review, test coverage or operational readiness. Prototyping is extremely useful for learning with users. The important part is the next step: move deliberately from a prototype to specifications, contracts, validation and delivery controls.

Can a non-developer lead an AI-assisted product experiment?

Yes, especially when the person understands the customer problem and the product decisions that need to be made. I am not a cloud-development or DevOps specialist, but a foundational understanding of logic helped me explore and ask better questions. A product leader does not have to approve every line of code. Their job is to make customer needs, scope, priorities, acceptance criteria and unresolved questions clear, while engineering, QA and DevOps expertise remains essential within the same product team. The goal is not one person carrying every decision; it is a customer-obsessed team building together.

Why should API contracts be owned as product artefacts?

Because an API is part of how a product works in the real world. It shapes how systems, partners and internal teams interact. Treating contracts as product artefacts makes customer needs, business rules and integration assumptions visible before implementation. It also gives the product team a stronger basis for planning and validating a slice of work. Contract First reduces the chance that people or agents will fill a business gap with a guess.

How do AI agents improve product and engineering alignment?

They can help expose gaps. When agents are asked to check completeness and raise open questions, they can make a large scope easier to understand, highlight missing requirements and reveal dependencies across UI, backend and infrastructure. But they do not create alignment by themselves. A team still needs a shared source of truth, clear ownership, working agreements and timely decisions. AI makes the value of those habits more visible.

Does AI reduce the need for QA and DevOps?

No. If anything, faster generation makes QA and DevOps expertise more important. QA helps the product team verify requirements through automated testing, regression, scenarios and coverage. DevOps helps make infrastructure deliberate, cost-aware, secure and operable. Agents can support both practices, but they should not replace the people responsible for the product being trustworthy for customers.

How should small HR Tech teams measure success with AI?

Do not rely only on output volume or headcount. Ask whether the team can move from a validated customer need to a production-quality increment with less rework and more predictability. Useful indicators include time to refine a slice, open questions found before development, cycle time, defect escape rate, coverage, deployment confidence, delivery against acceptance criteria and the autonomy of product-team members. Then compare those measures with customer and operational feedback.

Conclusion: AI amplifies the product system around it

AI is changing product development in HR Tech, but not because it makes good product judgment optional. It changes what a small product team can achieve when knowledge is no longer scattered only across conversations, documents and individual memory.

At SideUp, a legacy constraint forced us to look for another way. A prototype showed us both the promise and the limits of AI-assisted creation. The answer was not to hand control to agents. It was to make the practices that create dependable product work more explicit: narratives, contracts, small slices, open questions, version control, quality gates and shared accountability.

The four-day, post-Stitch experiment proved something was possible. The more important achievement was turning that possibility into a real product-team capability: one customer-obsessed team using Product, Engineering, QA and DevOps expertise, together with AI, to increase autonomy, speed and delivery precision.

If your organisation is experimenting with AI, the next question is not simply which tool to choose. It is this: what product, technical and operational context do we need to make explicit so our people—and their agents—can build the right thing with confidence?

Build better HR Tech with SideUp

SideUp is building a flexible employee benefits platform around what employees need in real life, while giving employers a more practical way to attract, retain and support their people. Our product journey is guided by customer obsession: software is a means to solve real customer problems, and technology should expand people’s capacity rather than make their work less human.

Want to see how SideUp can support your team? Book a 15-minute demo.

Important Links:

The HR Technology Trends 2026: AI is Expanding Jobs, Not Replacing Them

How to Measure Employee Retention: Metrics Every HR Leader Should Track

Employee Retention: Why Great Employees Leave Good Companies

Employee Retention: The Complete Guide to Keeping Great Employees in 2026