AI Will Build Exactly What You Ask for. In Ticketing, That's Exactly the Problem.

Two ticketing companies could sit down this month, open the same AI coding tool, and pay for the same subscription. Six weeks later, one of them has a purchase flow buyers trust and a scanner that survives a packed queue with spotty wifi. The other has something that technically works but embarrasses everyone who has to explain it to a client.

What separated them wasn't access to AI. Lyubomyr Nykyforuk, who has spent more than ten years building ticketing systems at Softjourn, has an explanation for why the gap shows up anyway: the tools stopped being the hard part a while ago. What's left is knowing exactly what to ask them for, and in a system as specific as ticketing, that turns out to be the most important part.

The Access Problem Was Never the Real Problem

For a while, the interesting question about AI and software development was whether the code would actually be any good. That question has quietly closed; the tools are in daily use across professional teams now, the output is competent, and everyone building a ticketing platform (including your competitors) is working from the same set of models.

Buyers might still be hoping the differentiator is better AI, sharper tools, a smarter model, or something in the stack a vendor has and a generic dev shop doesn't. Lyubomyr is direct about why that hope doesn't hold up, specifically on access to AI tools: "Your developers have the same access we do."

Raw access to a model is only part of the equation, though. How mature a team's AI-enabled development process is, the frameworks it uses for agentic workflows, its accumulated skills and prompt libraries, shapes the result just as much as the model itself. The real advantage is the specialized domain expertise that tells a team the pitfalls to expect, what to look for, what to avoid, and how to put that access to work.

Hallucination Isn't the Risk – Your Brief Is

If you ask Lyubomyr what typically goes wrong when AI builds a ticketing system, most people expect the answer to be about hallucination, with the model inventing something that isn't real. "That issue doesn't look entirely relevant to me anymore," he says.

"Hallucination was a problem in the development of AI models, the early ones." He isn't saying hallucination has completely disappeared, but that in his own work, it's rarely something that shows up. What he sees more often is a model doing exactly what it was asked – which sometimes becomes a different problem entirely – one that traces back to what went into the request in the first place.

His experience is that when the request carries enough context, the model uses it: "When I set the task clearly, whether it's ticketing, a payment system, or something else, if you put that knowledge into the request, it will use it. It doesn't have to make anything up." That sounds reassuring until you take it one step further: if the quality of the result depends on the quality of the brief, the problem hasn't disappeared; it's relocated, and now it sits with whoever is writing the brief.

For example, put the same task in front of two people, one who has delivered ticketing systems and one who hasn't, and even working from the same model and the same tools, you get two different systems. Only one of them knew what to put in the request in the first place.

What Ticketing Asks That a General Model Won't Volunteer

Ticketing is a specialized system, and building it effectively takes domain knowledge that starts with something as basic as the word itself. Search “ticketing system” and you're as likely to land on Zendesk or IT support software as anything related to event ticketing, because that's what the term “ticketing system” means to a general model with no other context.

Get past the vocabulary and a deeper gap opens up. A model can hold a general idea of what event ticketing is without holding any of the practical experience of actually building one. “Even if the model understands what ticketing is in general, it doesn't understand how to build effective access control, or how to design a seating layout that matches what buyers already expect from the market,” Lyubomyr says.

Asked where that practical knowledge actually shows up, he named five areas that come up most often:

• Access control under real conditions: large queues, unstable internet, offline support, and the data synchronization that has to follow it
• Peripheral device integrations: scanning hardware (camera versus laser, each with its own behavioral quirks) and box office printers, both of which behave differently once they're in a live event environment rather than a test one
• Payment processor integrations: the quirks attached to each one individually
• Seating layouts: built to match what buyers already expect from the market they're buying in
• Reporting: knowing which reports actually matter to an event organizer, how to present that data usefully, and what functionality around it is needed, this is as specific to ticketing as any of the above, and just as easy for a general model to get generically right but specifically wrong

None of these are surprising for anyone who's worked in ticketing, yet every one of these scenarios is the kind of requirement that tends to become obvious only after it's gone wrong once, on someone's project, at the worst possible moment.

The Baggage a Model Doesn't Have

“All of this comes with experience,” he says. “And AI doesn't have that baggage of past failures and successes to learn from. It may try to guess what would be best, but it doesn't know which corners we've already learned not to cut, and what has to be accounted for.”

He's seen what happens when that history is missing, in systems other teams have built. “I've personally seen systems developed by teams who had no knowledge in this area, and you could see they'd built them wrong. They used the wrong terminology, or they decomposed the functionality the wrong way.” 

Wrong terminology and wrong decomposition aren't cosmetic complaints. They're what a system looks like when it's been designed by someone reasoning from first principles about a domain that already has settled answers- answers the market, the venue, and the buyer all quietly expect the system to already know.

What Doesn't Change

With AI now writing a growing share of the actual code, a separate question follows: is that code still held to the same bar as code a developer writes by hand, or does the standard quietly loosen because a tool did the typing? Lyubomyr thinks not: “Code quality standards aren't going anywhere,” he says. “Whether AI writes it or a person writes the code by hand, in my perspective it makes no difference. The developer still bears responsibility for what they deliver.” The patterns, the review bar, the standards agreed on a project should all survive intact. What changed is only how the code gets produced, not what's expected of it once it exists.

What shifts when using agents is where developers spend their attention, moving from producing the code to setting the task and checking what comes back. “AI takes away a large part of the routine work,” says Lyubomyr, “but it doesn't take away your responsibility and expertise.”

Where This Leaves You, if You're Building a Ticketing Platform

None of this article should be used as an argument against using AI to help build a ticketing platform. Lyubomyr is emphatic that every stage of the development lifecycle is affected by AI now, and that all of it keeps getting faster and more advanced. Instead, he recommends:

• Treat the brief as the actual work: the result only ever reflects the quality of what went into the request, so the effort that used to happen mid-build now has to happen before a single line is generated.
• Supply domain requirements outright, don't expect the model to surface them: offline access control, printer behavior, seating logic, none of it gets raised unprompted. Someone in the room has to already know it belongs in the request.
• Verify against intent, not just output: working code isn't the bar. The bar is whether it matches what was actually meant and holds up to the standards set on the project.

The Tools Were Never the Advantage

Everyone has them now, including your competitors. What separates one build from another is knowing what to put in front of those tools. Every ticketing platform Softjourn has built has taught the team something no model can read anywhere: the requirement nobody thinks to mention until the queue is out the door and the connection has dropped.

That knowledge goes into the brief before a single line is generated. Build fast, by all means. Just make sure someone in the room already knows where it breaks.

If you're not sure your team has that knowledge yet, that's exactly what an AI readiness assessment with a Softjourn solution architect is for: a working session that maps what your platform actually needs against what's currently in your brief, before you spend a development cycle finding the gaps the hard way. Contact Softjourn to set one up.