Case study · June 1, 2026

How GolfNext Built an Agent-Ready Engineering Workflow

GolfNext runs software in the messy part of the real world.

The company, formerly known as GolfMore, provides digital infrastructure for golf venues: mobile apps, payments, self-service kiosks, ball dispensing, vouchers, access control, lockers, simulators, and venue administration. Public company material describes the platform as operating across hundreds of venues and many countries. That scale matters because the operational problem is not only software.

When something fails at a venue, the symptom can start in a kiosk, a cable, a controller board, a payment flow, an access rule, a locker, an integration, a log line, or a venue-specific configuration.

That is the kind of environment where "let's give developers AI tools" is too small a strategy.

The real question is whether AI can become part of the engineering operating model: repositories, tickets, specifications, quality gates, CI/CD, releases, logs, metrics, and eventually support.

That is the work Mavka helped GolfNext begin: moving from Claude Code practice to an agent-ready engineering workflow.

The starting point

GolfNext had already digitized a large part of golf venue operations. The product was not a simple SaaS dashboard where every incident lives inside one database and one web app.

The system touched physical infrastructure:

• kiosks at venues,
• payment and access flows,
• lockers and compartments,
• ball dispensing,
• controller boards,
• cables and device signals,
• venue-specific setup,
• logs spread across operational surfaces.

That created a support and engineering problem. First-line support needed to understand what was happening. Engineering needed tickets with enough technical context to act. Developers needed to ship changes without losing discipline. Releases needed stronger feedback from logs and metrics. Repeated incidents needed to become reusable diagnosis paths. And some of the most valuable knowledge still lived with the people who had debugged the weird cases before.

This is where most AI rollouts go sideways. The team starts with coding assistants, gets a few impressive demos, and stops there. But in a hardware-connected SaaS company, the larger prize is operational intelligence: using agents to make engineering, release management, and support work from the same context.

Phase 1: make engineering agent-ready

The first phase was not automation. It was practice.

Mavka ran a Claude Code workshop series for GolfNext:

• 10 sessions,
• 3 hours per session,
• 30 hours total.

The goal was to teach engineers to work with Claude Code as an engineering agent, not as a prompt toy. But the deeper goal was to make each repository ready for agent-assisted work.

That difference matters. A prompt toy gives you a snippet. An engineering agent works inside a repo, reads context, proposes diffs, runs checks, reacts to failures, and helps move a task toward a reviewed change. The engineer still owns the work. The agent changes the feedback loop.

The workshop focused on the practical habits developers need before serious delegation is possible:

• giving the agent enough context before asking for code,
• breaking work into small tasks,
• reviewing diffs instead of trusting generated output,
• running verification before accepting changes,
• keeping domain judgment with the engineer,
• using the repo as the source of truth,
• working from a specification instead of a loose prompt.

For a real engineering team, that also means setup work. Each repository needs a clear definition of done. The agent needs to know which commands prove a change is acceptable. It needs project-specific rules, skills, coding conventions, and boundaries. It needs access to the repository, tickets, documentation, and the communication history that explains why decisions were made.

By the end of this phase, the expected capability is not "developers can prompt Claude." It is this: developers can scope agent tasks, write usable specs, prepare repository context, review generated changes, run verification, and identify what context the agent still lacks.

Phase 2: connect agents to delivery context

The next step is to look beyond individual coding sessions.

Anthropic describes Claude Code Routines as saved Claude Code configurations that can run on a schedule, through API calls, or from GitHub events on Anthropic-managed cloud infrastructure. In practice, that makes Routines a useful bridge between interactive agent work and deeper custom automation.

For GolfNext, the natural use cases are not flashy. They are delivery-oriented:

• understanding CI and CD bottlenecks,
• checking whether different repositories have the right quality gates,
• preparing context before an engineer starts a fix,
• turning repeated investigation steps into reusable routines,
• making build, test, and deploy feedback easier for an agent to act on.

This phase is where an agent starts to understand the delivery path, not only the code. It should know the difference between a low-risk UI change, a payment-flow change, a kiosk integration change, and a release that touches device behavior. Those changes should not all pass through the same level of scrutiny.

That requires different levels of quality gates: linting and type checks for simple changes, focused tests for business logic, integration checks for risky paths, and stronger release checks for operational surfaces. It also means looking at CI/CD as part of the AI adoption project. If the pipeline is slow, flaky, or unclear, the agent inherits that friction.

Where possible, the agent should also get read-only operational context: logs, metrics, release history, and sanitized production-like data. If a read-only production replica is available, it should be anonymized and constrained. The point is not to give the agent uncontrolled access. The point is to give it enough trusted context to reason about real behavior.

Phase 3: add post-release intelligence

Once agents understand the repository and the delivery path, the next step is release intelligence.

Most AI coding workflows stop at the pull request. That is too early. In a connected infrastructure business, the important question often appears after deployment:

• Did the feature behave as expected?
• Did error rates change?
• Did performance degrade?
• Did a payment, access, kiosk, locker, or device flow start producing unusual logs?
• Did support receive new reports that correlate with the release?

This is where AI can help close the loop between shipping and observing. After a release, an agent can review logs, metrics, error traces, and known business flows. It can compare before-and-after behavior, summarize anomalies, and prepare a post-release report for the team.

The agent is not declaring production healthy on its own. It is doing the repetitive analysis that makes the human release owner better informed.

Phase 4: delegate selected engineering tasks

Only after those foundations are in place does deeper delegation become realistic.

At this stage, a developer can assign selected tasks to an agent through a strong ticket or specification. Claude Code Routines can turn recurring tasks into pull requests. The developer's role changes: less manual implementation for suitable work, more ownership of the specification, review, release plan, and production verification.

That is a meaningful shift, but it is not a handoff of responsibility. The human still decides what should be built, whether the pull request satisfies the definition of done, whether the change is safe to release, and whether deployment succeeded.

The agent can draft the PR. The developer owns the engineering judgment.

Phase 5: automate support workflows

Support automation is more credible after the engineering system is already agent-ready.

Consider a realistic incident pattern.

A self-service kiosk communicates with a controller board. The board controls opening and closing of lockers or compartments. A noisy cable between the kiosk and the board creates unreliable signals. From the outside, support may see intermittent behavior: a locker does not open consistently, a command appears to work and then fails, or a venue reports symptoms that sound like software but may be hardware.

A human expert can connect those dots because they have seen the pattern before. A new support person may not. An engineer can find the truth eventually, but only after reconstructing the venue, device, logs, hardware behavior, and past incidents.

That is exactly the kind of work a support agent can assist with.

The agent's role is not to replace support. It is to prepare the case:

• interpret the reported symptom,
• inspect relevant logs or structured device context,
• compare the case with known failure patterns,
• explain likely causes in support-friendly language,
• suggest the next diagnostic step,
• create an engineering-grade ticket when escalation is needed.

The ticket is the product of the agent's work. A vague report like "locker sometimes does not open" becomes a structured handoff: venue, device, recent commands, relevant logs, suspected failure pattern, confidence level, and next diagnostic step.

This is where AI starts to change operations, not just coding speed. But it works because the earlier phases created the foundation: repository rules, specifications, quality gates, delivery context, release feedback, and human review discipline.

Why this is different from a coding assistant rollout

Most AI coding rollouts measure the wrong thing. They ask whether developers can write code faster.

That matters, but it is not enough for a company like GolfNext.

The expensive part of an incident or release is often not the code change. It is the diagnosis:

• What exactly happened?
• Which device or integration was involved?
• Has this happened before?
• Is this a software bug, a configuration issue, a hardware signal problem, or a payment/access edge case?
• Does support have enough information to act?
• Does engineering have enough information to reproduce it?
• Did the release introduce the behavior, or did it reveal an existing problem?
• Which quality gate should have caught this earlier?

AI is useful here because the work is context-heavy and repeatable. The same patterns come back. The same logs need to be checked. The same known failure modes need to be compared. The same ticket quality problems slow engineering down.

The operational win is not "AI writes more code." The win is that developers, release owners, support, and engineering managers share a better understanding of the system sooner.

The maturity model

The path from workshop to support automation is easier to understand as a maturity model.

The important detail is sequencing. A custom support agent is more likely to work when the team has already learned how to give agents context, review their output, encode operational knowledge, and connect agent work to quality gates and production feedback.

What GolfNext can compound

The compounding value is knowledge capture.

Every time engineering ships a change, the organization can improve the system that helps the next change ship safely. A repeated CI failure becomes a clearer quality gate. A confusing deployment becomes a release checklist. A production anomaly becomes a post-release check. A strange hardware signal issue becomes a runbook. A repeated payment edge case becomes a diagnosis path. A confusing escalation becomes a better ticket template. A senior engineer's explanation becomes reusable context.

Over time, this reduces the amount of operational knowledge trapped in individual heads.

That does not remove senior engineers or experienced support people from the loop. It changes where their time goes. Instead of answering the same diagnostic questions repeatedly, they improve the system that answers them the next time.

The broader pattern

GolfNext is not unique in having this shape of problem. It is part of a larger class of companies where software operates connected physical infrastructure.

In industrial IoT, field service, and SRE environments, AI agents are increasingly used to connect symptoms, logs, device context, historical incidents, and runbooks. The closest public examples point in the same direction:

• Multi-agent incident management for connected infrastructure, such as the DeLaval and Arelion example described by ZenML.
• GenAI assistance for DevOps and SRE incident work, such as DataArt's Fiberplane case study.
• AI support for field technicians retrieving service history, such as SoftServe's ServiceTrade proof of concept.
• Operational visibility for IoT platforms, such as N-iX's IoT operations case study.

The shared pattern is simple: agents are useful when the work requires reading a lot of context, comparing it to known patterns, and preparing the next human action.

That is why GolfNext's path is bigger than a Claude Code workshop. The workshop was the entry point. The deeper work is agent-ready engineering: repositories, specs, quality gates, releases, logs, metrics, and support workflows shaped so agents can help without removing human ownership.

The takeaway

For hardware-connected SaaS companies, AI adoption should not stop at developer productivity.

The better question is:

Can AI help the organization understand the system faster?

For GolfNext, the answer starts with engineers who know how to work with agents. It continues with repositories that have clear rules, tickets that become usable specifications, quality gates that agents can run, delivery pipelines that reveal bottlenecks, and post-release checks that compare expected behavior against reality.

That is the useful version of AI adoption: not a demo, not a prompt library, not a vague promise of automation.

A developer gets a better workflow. A release owner gets clearer feedback. A support person gets a stronger diagnosis. An engineer gets a better ticket. A repeated incident becomes a repeatable workflow. The company keeps more of its operational knowledge inside the system instead of inside a few people's heads.

That is where agents start to matter.