Language models don’t just make mistakes—they fabricate reality with complete confidence. An AI agent might claim it created database records that don’t exist, or insist it performed actions it never attempted. For teams deploying these systems in production, that distinction determines how you fix the problem.
Dmytro Kyiashko specializes in testing AI systems. His work focuses on one question: how do you systematically catch when a model lies?
The Problem With Testing Confident Nonsense
Traditional software fails predictably. A broken function returns an error. A misconfigured API provides a deterministic failure signal—typically a standard HTTP status code and a readable error message explaining what went wrong.
Language models break differently. They’ll report completing tasks they never started, retrieve information from databases they never queried, and describe actions that exist only in their training data. The responses look correct. The content is fabricated.
“Every AI agent operates according to instructions prepared by engineers,” Kyiashko explains. “We know exactly what our agent can and cannot do.” That knowledge becomes the foundation for distinguishing hallucinations from errors.
If an agent trained to query a database fails silently, that’s a bug. But if it returns detailed query results without touching the database? That’s a hallucination. The model invented plausible output based on training patterns.
Validation Against Ground Truth
Kyiashko’s approach centers on verification against actual system state. When an agent claims it created records, his tests check if those records exist. The agent’s response doesn’t matter if the system contradicts it.
“I typically use different types of negative tests—both unit and integration—to check for LLM hallucinations,” he notes. These tests deliberately request actions the agent lacks permission to perform, then validate the agent doesn’t falsely confirm success and the system state remains unchanged.
One technique tests against known constraints. An agent without database write permissions gets prompted to create records. The test validates no unauthorized data appeared and the response doesn’t claim success.
The most effective method uses production data. “I use the history of customer conversations, convert everything to JSON format, and run my tests using this JSON file.” Each conversation becomes a test case analyzing whether agents made claims contradicting system logs.
This catches patterns synthetic tests miss. Real users create conditions exposing edge cases. Production logs reveal where models hallucinate under actual usage.
Two Evaluation Strategies
Kyiashko uses two complementary approaches to evaluate AI systems.
Code-based evaluators handle objective verification. “Code-based evaluators are ideal when the failure definition is objective and can be checked with rules. For example: parsing structure, checking JSON validity or SQL syntax,” he explains.
But some failures resist binary classification. Was the tone appropriate? Is the summary faithful? Is the response helpful? “LLM-as-Judge evaluators are used when the failure mode involves interpretation or nuance that code can’t capture.”
For the LLM-as-Judge approach, Kyiashko relies on LangGraph. Neither approach works alone. Effective frameworks use both.
What Classic QA Training Misses
Experienced quality engineers struggle when they first test AI systems. The assumptions that made them effective don’t transfer.
“In classic QA, we know exactly the system’s response format, we know exactly the format of input and output data,” Kyiashko explains. “In AI system testing, there’s no such thing.” Input data is a prompt—and the variations in how customers phrase requests are endless.
This demands continuous monitoring. Kyiashko calls it “continuous error analysis”—regularly reviewing how agents respond to actual users, identifying where they fabricate information, and updating test suites accordingly.
The challenge compounds with instruction volume. AI systems require extensive prompts defining behavior and constraints. Each instruction can interact unpredictably with others. “One of the problems with AI systems is the huge number of instructions that constantly need to be updated and tested,” he notes.
The knowledge gap is significant. Most engineers lack clear understanding of appropriate metrics, effective dataset preparation, or reliable methods for validating outputs that change with each run. “Making an AI agent isn’t difficult,” Kyiashko observes. “Automating the testing of that agent is the main challenge. From my observations and experience, more time is spent testing and optimizing AI systems than creating them.”
Reliable Weekly Releases
Hallucinations erode trust faster than bugs. A broken feature frustrates users. An agent confidently providing false information destroys credibility.
Kyiashko’s testing methodology enables reliable weekly releases. Automated validation catches regressions before deployment. Systems trained and tested with real data handle most customer requests correctly.
Weekly iteration drives competitive advantage. AI systems improve through adding capabilities, refining responses, expanding domains.
Why This Matters for Quality Engineering
Companies integrating AI grow daily. “The world has already seen the benefits of using AI, so there’s no turning back,” Kyiashko argues. AI adoption accelerates across industries—more startups launching, more enterprises integrating intelligence into core products.
If engineers build AI systems, they must understand how to test them. “Even today, we need to understand how LLMs work, how AI agents are built, how these agents are tested, and how to automate these checks.”
Prompt engineering is becoming mandatory for quality engineers. Data testing and dynamic data validation follow the same trajectory. “These should already be the basic skills of test engineers.”
The patterns Kyiashko sees across the industry confirm this shift. Through his work reviewing technical papers on AI evaluation and assessing startup architectures at technical forums, the same issues appear repeatedly: teams everywhere face identical problems. The validation challenges he solved in production years ago are now becoming universal concerns as AI deployment scales.
Testing Infrastructure That Scales
Kyiashko’s methodology addresses evaluation principles, multi-turn conversation assessment, and metrics for different failure modes.
The core concept: diversified testing. Code-level validation catches structural errors. LLM-as-Judge evaluation enables assessment of AI system effectiveness and accuracy depending on which LLM version is being used. Manual error analysis identifies patterns. RAG testing verifies agents use provided context rather than inventing details.
“The framework I describe is based on the concept of a diversified approach to testing AI systems. We use code-level coverage, LLM-as-Judge evaluators, manual error analysis, and Evaluating Retrieval-Augmented Generation.” Multiple validation methods working together catch different hallucination types that single approaches miss.
What Comes Next
The field defines best practices in real time through production failures and iterative refinement. More companies deploy generative AI. More models make autonomous decisions. Systems get more capable, which means hallucinations get more plausible.
But systematic testing catches fabrications before users encounter them. Testing for hallucinations isn’t about perfection—models will always have edge cases where they fabricate. It’s about catching fabrications systematically and preventing them from reaching production.
The techniques work when applied correctly. What’s missing is widespread understanding of how to implement them in production environments where reliability matters.
Dmytro Kyiashko is a Software Developer in Test specializing in AI systems testing, with experience building test frameworks for conversational AI and autonomous agents. His work examines reliability and validation challenges in multimodal AI systems.
