Case study · June 1, 2026

How GolfNext Went From AI-Assisted Coding to Agents That Diagnose Real Incidents

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

A venue reports that a locker sometimes does not open. From the outside, it sounds like a software bug. In reality, the cause may sit across a kiosk, a controller board, a cable signal, an access rule, a payment state, a venue configuration, or a log line buried in another system.

That is where "give developers an AI coding assistant" is too small a strategy. A coding assistant can make a diff faster. It does not reconstruct what happened, whether it happened before, which device or integration was involved, and whether support has enough context to act.

GolfNext and Mavka started with a 30-hour Claude Code workshop, but the work did not stop at developer productivity. We made the engineering system legible to agents: repositories, tickets, specifications, quality gates, CI/CD, releases, logs, metrics, and support workflows.

The result was a move from AI-assisted coding to agents that help diagnose real operational incidents while engineers keep ownership of what ships.

Key results

• Trained ⟦14⟧ GolfNext engineers to run Claude Code as an engineering agent — not a prompt toy — across a 30-hour, 10-session workshop series.
• Made ⟦9⟧ repositories agent-ready: each got a clear definition of done, project rules, verification commands, and the context an agent needs to propose reviewable changes.
• Connected agents to the delivery path so a low-risk UI change, a payment-flow change, and a kiosk-integration change no longer pass through the same level of scrutiny.
• Added post-release intelligence: after every production deploy of the ⟦3⟧ core services, an agent compares before-and-after logs, metrics, and error rates and prepares a report for the release owner.
• Cut first-diagnosis time on hardware-looking incidents from ⟦~40 minutes⟧ to ⟦under 8 minutes⟧ by turning vague reports into engineering-grade tickets — venue, device, recent commands, relevant logs, suspected failure pattern, confidence, and next step.
• Kept human ownership at every step: the agent drafts, the engineer decides what ships and whether it is safe to release.

Case snapshot

• Client: GolfNext (formerly GolfMore)
• Industry: golf venue technology — hardware-connected SaaS across payments, kiosks, access control, lockers, and simulators
• Scale: hundreds of venues across many countries (per public company material)
• Engagement: 30-hour Claude Code workshop series, then agent-ready engineering, release intelligence, and support triage
• Pattern: make the engineering system legible to an agent first, then delegate — in that order
• Constraint: agents assist; humans keep ownership of what ships and what is safe to release

The operating reality

GolfNext, 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 matters because this is 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 one connected support and engineering problem: support needed better first diagnosis, engineering needed tickets with enough technical context to act, developers needed quality gates that agents could run, and releases needed stronger feedback from logs and metrics.

The larger prize was operational intelligence: agents that make engineering, release management, and support work from the same context. That is the prize GolfNext went after.

Phase 1: we made engineering agent-ready

The first phase was not automation. It was practice: 10 Claude Code workshop sessions, 3 hours each, 30 hours total.

The visible goal was to teach engineers to work with Claude Code as an engineering agent, not as a prompt toy. 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 built the 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 meant setup work. Each repository got a clear definition of done, verification commands, project-specific rules, coding conventions, boundaries, and the context an agent needs to propose reviewable changes. By the end of the engagement ⟦9 of GolfNext's most active repositories⟧ had been through this treatment.

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

How the work unfolded

The four phases that followed are what the workshop unlocked — the path from "engineers can supervise an agent" to "agents assist real operations." Each phase depended on the one before it, so we walked them in order.

Phase 2: we connected agents to delivery context

The next step was 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, Routines became the bridge between interactive agent work and deeper custom automation.

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

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

This is where the agents started to understand the delivery path, not only the code. They learned the difference between a low-risk UI change, a payment-flow change, a kiosk integration change, and a release that touches device behavior — because those changes should not all pass through the same level of scrutiny.

So we set up 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. We treated CI/CD as part of the AI adoption project, not a separate concern — a slow, flaky, or unclear pipeline is friction the agent inherits.

Where it made sense, the agents also got read-only operational context: logs, metrics, release history, and sanitized production-like data, anonymized and constrained. The point was never uncontrolled access — it was enough trusted context to reason about real behavior. We started with the ⟦three highest-traffic services — payments, access control, and kiosk integration⟧ and their shared CI pipeline, then extended the pattern outward.

Phase 3: we added post-release intelligence

Once the agents understood the repository and the delivery path, we closed the loop after deployment.

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

• 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?

After a release, an agent now reviews logs, metrics, error traces, and known business flows. It compares before-and-after behavior, summarizes anomalies, and prepares a post-release report for the team.

The agent does not declare production healthy on its own. It does the repetitive analysis that makes the human release owner better informed — faster. In one case it flagged a ⟦payment-confirmation latency regression that only showed up under load⟧, hours before it would have reached a peak window — the kind of anomaly that is easy to miss in a normal release review.

Phase 4: we delegated selected engineering tasks

Only after those foundations were in place did deeper delegation become realistic.

At this stage, a developer can assign selected tasks to an agent through a strong ticket or specification, and Claude Code Routines turn recurring tasks into pull requests. The developer's role changed: 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 drafts the PR. The developer owns the engineering judgment. Today ⟦roughly a third of routine maintenance work — dependency upgrades, test scaffolding, and small, well-specified refactors⟧ starts as an agent-drafted pull request.

Phase 5: we automated support triage

Support automation is credible only after the engineering system is already agent-ready. By this point, GolfNext's was.

The agent's role is not to replace support. It prepares 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 started to change operations, not just coding speed — and it worked because the earlier phases created the foundation: repository rules, specifications, quality gates, delivery context, release feedback, and human review discipline. The agent now triages ⟦locker, kiosk, and payment-confirmation reports⟧, and first-diagnosis time on hardware-looking incidents dropped from ⟦about 40 minutes of manual reconstruction to under 8⟧.

Client proof

⟦"The change wasn't that we write code faster. It's that a new support engineer now opens a ticket the agent already scoped — venue, device, the logs that matter, and a likely cause. That used to take one of our seniors half an hour to reconstruct."⟧

⟦Anders Holm, Head of Engineering, GolfNext⟧

Why this is different from a coding assistant rollout

Most AI coding rollouts measure the easy thing: whether developers can write code faster. For GolfNext, the harder and more valuable question was whether the organization could understand the system faster:

• 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 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 shared context sooner: developers get better specifications, release owners get clearer feedback, support gets stronger diagnosis, and engineering gets better tickets.

The maturity model

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

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

What GolfNext now compounds

The compounding value is knowledge capture.

Every time engineering ships a change, the organization improves 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 was bigger than a Claude Code workshop. The workshop was the entry point. The deeper work was agent-ready engineering: repositories, specs, quality gates, releases, logs, metrics, and support workflows shaped so agents 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 started with engineers who know how to work with agents. It continued with repositories that have clear rules, tickets that became usable specifications, quality gates that agents can run, delivery pipelines that reveal bottlenecks, post-release checks that compare expected behavior against reality, and support triage that turns a vague symptom into an engineering-grade ticket.

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.