{"id":2374,"date":"2026-08-29T12:45:11","date_gmt":"2026-08-29T12:45:11","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/all-things-azure\/?p=2374"},"modified":"2026-08-29T12:48:14","modified_gmt":"2026-08-29T12:48:14","slug":"only-believe-what-you-can-validate","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/all-things-azure\/only-believe-what-you-can-validate\/","title":{"rendered":"Only believe what you can validate: a verification framework for agentic AI"},"content":{"rendered":"

How to read this article<\/span><\/h2>\n

This article picks up where my January piece<\/a> left off. My catch phrase is still the same: “only believe what you can validate”<\/em><\/i>. This article is about validation.<\/span><\/p>\n

If you are new to agentic AI (in modernization contexts), I would highly recommend reading The Realities of Application Modernization with Agentic AI<\/a> first. Start there, then come back.<\/span><\/p>\n

The problem with “looks good to me”<\/span><\/h2>\n

I have had a version of the same conversation many times over the last months. I work with a customer on an agentic application modernization. In this concrete example we are facing one of 150 COBOL modules with 10 related copybooks. The customer’s experts chose this module intentionally as it is “fairly isolated”. The agent works for five minutes and generates the reverse engineering documentation of the module for us: a markdown file with over 2500 words, longer than the draft of this article. I ask: “alright, is this what you would expect?<\/em><\/i>” The room goes quiet. Blank stares. Then: “Looks good to me on first glance”<\/em><\/i>, often followed by a “do you expect me now to read through everything?”<\/em><\/i><\/span><\/p>\n

And the person is right. It does look good. They quickly scanned the first 10-20 lines. The record layout is described correctly. So they conclude the rest is probably correct as well. Reasonable conclusion at first glance. But what is easy to verify is usually also easy to get right, for the model too. So it probably is correct, but it does not hold any significance for the rest of the document.<\/span><\/p>\n

The knowledge captured in that module took decades to develop, and the agent claims to have extracted it in five minutes. And in this moment they have no easy way to determine which of these 2500 words are correct, hallucinated, or misinterpreted, and which words are missing. They are facing this massive document and would need to read through it thoroughly, which would take hours. Just as a reminder: this module is one of the easier ones. What will happen if they feed the agentic AI larger modules with more dependencies?<\/span><\/p>\n

My first impulse is to say: “well, of course I do. How else would we be able to determine if the agentic output is sufficient?”<\/em><\/i> But obviously it is not that easy. It will never scale. It will overload the experts and create AI fatigue. And that’s fair enough. So the question is, how do we solve this problem?<\/span><\/p>\n

The problem is that agentic AI produces a lot of output in minutes, and that output looks complete, coherent, and confident. And if we are honest, this is a problem we have with every agentic AI output. But in some use cases, and app modernization is one of them, accuracy matters more and the consequences of getting it wrong are more severe, especially when we talk about core business cases of organizations.<\/span><\/p>\n

“Most things look right” in a mission-critical system is not the same as correct.<\/span><\/p>\n

The tech can’t hold up to the expectations<\/span><\/h2>\n

As a model’s context window fills up, two effects kick in: Below 50% capacity, middle tokens degrade – the model retains the beginning and end but loses what is in between. Above 50%, even the beginning decays. The model continues to produce confident output.<\/span><\/p>\n

These effects are widely known as context rot. If you want to learn more, I recommend: producttalk.org\/context-rot<\/a><\/span><\/p>\n

The other extreme is not providing enough context. Either way, the result is one of three specific failure modes.<\/span><\/p>\n

    \n
  1. The miss.<\/strong><\/b> The AI overlooked something that should have been included, resulting in incomplete output while nothing is technically wrong.<\/span><\/li>\n<\/ol>\n
      \n
    1. The hallucination.<\/strong><\/b> The AI produced something plausible that does not exist or is not true. Looks good, still wrong.<\/span><\/li>\n<\/ol>\n
        \n
      1. The misinterpretation.<\/strong><\/b> The AI tried to follow slightly vague instructions to the best of its knowledge and still produced the wrong outcome.<\/span><\/li>\n<\/ol>\n

        Now we know the core of the problem and the answer, obviously, is verification.<\/span><\/p>\n

        The three actors in any verification story<\/span><\/h2>\n

        \"verification<\/a><\/p>\n

        Verification involves three parties: humans<\/strong><\/b>, AI<\/strong><\/b>, and deterministic tools<\/strong><\/b>. Each pair has a specific failure mode.<\/span><\/p>\n

        “You are absolutely right.”<\/em><\/i>: When AI misses something and a human is lucky and catches it, AI just fixes the found problem unless actively prompted to find the root cause.<\/span><\/p>\n

        “I miserably failed you.”<\/em><\/i>: When AI produces something that compiles but is factually wrong, deterministic tools are unlikely to catch the problem, which results in a green pipeline and the problem getting shipped to production.<\/span><\/p>\n

        “I have to automate this?”<\/em><\/i>: Automation has always been hard. And there is still this wrong mental model: if a task only needs 5 seconds to be done manually, why spend the effort to automate it. This technical process debt becomes visible way too late and is another root cause why agentic AI adoption stalls.<\/span><\/p>\n

        It became clear that none of these three actors can work alone and scale, so how do we combine them to become safe with real verification? How do we define the question mark in the middle?<\/span><\/p>\n

        While researching this matter, two things became clear to me: agentic AI output is only as good as its verification mechanism<\/strong><\/b>, but not every verification mechanism has the same significance in every context.<\/span><\/p>\n

        You can choose the best LLM with the best benchmarks, but its output does not matter. What matters is your ability to tell how good it is. And to determine this, I tried to create a framework\/mental model to help simplify answering the question “what good looks like”.<\/span><\/p>\n

        An iterative verification framework<\/span><\/h2>\n

        Verification should always be seen iteratively. If you skip the bare minimum the advanced checks lose reliability. Across all disciplines the six core questions you need to answer to verify the output of agentic AI are essentially the same:<\/span><\/p>\n

          \n
        • What is the check?<\/strong><\/b> The concrete thing you run, review, or measure.<\/span><\/li>\n
        • What does it cost to build?<\/strong><\/b> Money, time, expertise, access to production data.<\/span><\/li>\n
        • Who performs it?<\/strong><\/b> Deterministic tooling, AI, or a human. Often a combination.<\/span><\/li>\n
        • What does it actually prove?<\/strong><\/b> Be honest about what you are actually learning by performing this check.<\/span><\/li>\n
        • What is the result?<\/strong><\/b> A concrete, tangible and easy to act on artifact.<\/span><\/li>\n
        • What tools exist to help?<\/strong><\/b><\/span><\/li>\n<\/ul>\n

          The output is not only the table. Most teams have never tried the exercise of actually writing down the de facto verification model that already exists implicitly in the expert’s heads. It was just never documented, and therefore probably inconsistent and invisible. At the same time, writing the verification model down names it – and naming it is the first step to improving it. That exercise is what makes it possible to identify that the value of certain bare minimum checks is “almost nothing”. The framework is just a helper.<\/span><\/p>\n

          Below, I show two examples of how I would build verification layers for reverse engineering and code generation output done by agentic AI (these are currently the most relevant in my work domain).<\/span><\/p>\n

          Disclaimer: This is an opinionated POV, your criteria might be different, your domain might be different.<\/span><\/code><\/p><\/blockquote>\n

          Reverse engineering<\/span><\/h2>\n

          When applying the framework to reverse engineering, the verification layers could look like the following:<\/span><\/p>\n\n\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n
          \n

          Level<\/strong><\/b><\/span><\/p>\n<\/th>\n

          		\n

          Check<\/strong><\/b><\/span><\/p>\n<\/th>\n

          		\n

          Cost to build<\/strong><\/b><\/span><\/p>\n<\/th>\n

          		\n

          Check performed by<\/strong><\/b><\/span><\/p>\n<\/th>\n

          		\n

          What it actually proves \/ result<\/strong><\/b><\/span><\/p>\n<\/th>\n

          		\n

          Tool examples<\/strong><\/b><\/span><\/p>\n<\/th>\n<\/tr>\n

          \n

          0a<\/span><\/p>\n<\/td>\n

          		\n

          All referenced entities exist in the codebase; codebase is fully represented in the output<\/span><\/p>\n<\/td>\n

          		\n

          Low<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic<\/span><\/p>\n<\/td>\n

          		\n

          No hallucinations, everything captured;<\/span>\nResult: complete entity map of the code<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          Custom scripts, SonarQube, AppCAT, dependency scanners;<\/span>\ncobol-rekt, CAST<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          0b<\/span><\/p>\n<\/td>\n

          		\n

          Output follows provided documentation standards; no redundancies<\/span><\/p>\n<\/td>\n

          		\n

          Low<\/span><\/p>\n<\/td>\n

          		\n

          AI<\/span><\/p>\n<\/td>\n

          		\n

          Output is structurally coherent,<\/span>\nfollows agreed conventions;<\/span>\nResult: list of deviations from the standard<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          Agentic AI<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          1<\/span><\/p>\n<\/td>\n

          		\n

          Domain expert confirms or corrects the extracted business rules in one module<\/span><\/p>\n<\/td>\n

          		\n

          Low<\/span><\/p>\n<\/td>\n

          		\n

          Human<\/span><\/p>\n<\/td>\n

          		\n

          Spot test, accuracy for reviewed scope;<\/span>\nResult: every business rule in that module<\/em><\/i><\/span>\nmarked confirmed or corrected<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          Manual review<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          2<\/span><\/p>\n<\/td>\n

          		\n

          Based on the use case description, tests are generated and executed against the source<\/span>\nsystem; 100% test coverage for described use cases<\/span><\/p>\n<\/td>\n

          		\n

          Medium<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic + AI<\/span><\/p>\n<\/td>\n

          		\n

          Documented behavior matches source<\/span>\nsystem behavior for captured use cases;<\/span>\nResult: pass\/fail per use case<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          common testing frameworks, custom scripts,<\/span>\nAgentic AI for test generation<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          3<\/span><\/p>\n<\/td>\n

          		\n

          Domain expert confirms or corrects every extracted business rule, across full scope or representative sample<\/span><\/p>\n<\/td>\n

          		\n

          High<\/span><\/p>\n<\/td>\n

          		\n

          Human<\/span><\/p>\n<\/td>\n

          		\n

          All business rules are correctly captured;<\/span>\nResult: every extracted rule marked confirmed<\/em><\/i><\/span>\nor corrected, plus a correction rate<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          Manual review, structured interviews<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          4<\/span><\/p>\n<\/td>\n

          		\n

          Documented behavior validated against production execution traces<\/span><\/p>\n<\/td>\n

          		\n

          High + operational<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic + Human<\/span><\/p>\n<\/td>\n

          		\n

          Runtime check; covers edge-case behavior;<\/span>\nResult: documented behavior never observed in<\/em><\/i><\/span>\ntraces, and observed behavior not documented<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          OpenTelemetry, Datadog, Dynatrace;<\/span>\nIBM OMEGAMON \/ Compuware Strobe (mainframe)<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          5<\/span><\/p>\n<\/td>\n

          		\n

          Documentation continuously validated against live system; divergence triggers alert<\/span><\/p>\n<\/td>\n

          		\n

          Very high + operational<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic<\/span><\/p>\n<\/td>\n

          		\n

          Documentation consistency becomes<\/span>\nongoing guarantee;<\/span>\nResult: an alert per divergence<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          OpenTelemetry + custom assertion pipeline, contract testing frameworks<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          Code generation<\/span><\/h2>\n

          Applying the framework to code generation is way less fuzzy than reverse engineering, as the quality gates for good AI-generated code are the same as for traditionally written code. So in a perfect world, in a mature software engineering culture, this should already be in place, which makes it easier to “just apply” to AI-generated output.<\/span><\/p>\n\n\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n\n\n
          \n

          Level<\/strong><\/b><\/span><\/p>\n<\/th>\n

          		\n

          Check<\/strong><\/b><\/span><\/p>\n<\/th>\n

          		\n

          Cost to build<\/strong><\/b><\/span><\/p>\n<\/th>\n

          		\n

          Check performed by<\/strong><\/b><\/span><\/p>\n<\/th>\n

          		\n

          What it actually proves \/ result<\/strong><\/b><\/span><\/p>\n<\/th>\n

          		\n

          Tool examples<\/strong><\/b><\/span><\/p>\n<\/th>\n<\/tr>\n

          \n

          0a<\/span><\/p>\n<\/td>\n

          		\n

          Compiles and is executable<\/span><\/p>\n<\/td>\n

          		\n

          Free*<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic + AI<\/span><\/p>\n<\/td>\n

          		\n

          That’s the bare minimum;<\/span>\nResult: build succeeds, or a build log with errors<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          javac, dotnet build, Maven, Gradle, Agentic AI*<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          0b<\/span><\/p>\n<\/td>\n

          		\n

          Linting does not flag serious violations of coding guidelines<\/span><\/p>\n<\/td>\n

          		\n

          Low<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic<\/span><\/p>\n<\/td>\n

          		\n

          Syntax is correct, coding standards are fulfilled;<\/span>\nResult: list of violations by severity<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          ESLint, SonarQube, Checkstyle, PMD, Pylint<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          0c<\/span><\/p>\n<\/td>\n

          		\n

          Security scan flags no high\/critical vulnerabilities; no known CVEs in dependencies<\/span><\/p>\n<\/td>\n

          		\n

          Low<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic<\/span><\/p>\n<\/td>\n

          		\n

          Generated code doesn’t introduce known vulnerability patterns or vulnerable dependency versions;<\/span>\nResult: list of findings by severity, with CVE references<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          Snyk, Checkmarx, Semgrep, OWASP Dependency Check, GitHub Dependabot<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          1<\/span><\/p>\n<\/td>\n

          		\n

          Unit testing covers existing code base including edge cases<\/span><\/p>\n<\/td>\n

          		\n

          Low<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic<\/span><\/p>\n<\/td>\n

          		\n

          Correct for the explicitly tested paths; reveals obvious regressions;<\/span>\nResult: pass\/fail per test, plus a coverage number<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          JUnit, NUnit, pytest, Jest<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          2<\/span><\/p>\n<\/td>\n

          		\n

          Components interact correctly with adjacent systems (integration testing)<\/span><\/p>\n<\/td>\n

          		\n

          Medium<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic<\/span><\/p>\n<\/td>\n

          		\n

          Integration seams are correct; generated code connects to infrastructure as expected;<\/span>\nResult: pass\/fail per integration test<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          Testcontainers, WireMock, Spring Integration Test, pytest<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          3<\/span><\/p>\n<\/td>\n

          		\n

          Identical results on a representative sample and production-representative data set, volume & distribution<\/span><\/p>\n<\/td>\n

          		\n

          Medium<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic + Human<\/span><\/p>\n<\/td>\n

          		\n

          Correct for the input shapes of the sample and real data distribution, including edge cases;<\/span>\nResult: diff report of mismatching records<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          Custom test harnesses, database diff tools, pytest fixtures, CI\/CD<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          4<\/span><\/p>\n<\/td>\n

          		\n

          Response times, throughput, and resource usage meet or exceed source system SLAs<\/span><\/p>\n<\/td>\n

          		\n

          Medium\u2013High<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic + Human<\/span><\/p>\n<\/td>\n

          		\n

          Functionally correct code is also operationally viable; no silent performance regression;<\/span>\nResult: latency, throughput and resource numbers against the SLA thresholds<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          JMeter, k6, Gatling, Azure Load Testing<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          5<\/span><\/p>\n<\/td>\n

          		\n

          Critical path e2e coverage<\/span><\/p>\n<\/td>\n

          		\n

          High<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic + Human<\/span><\/p>\n<\/td>\n

          		\n

          Critical business paths produce correct end-to-end outcomes; reveals integration failures invisible to unit tests;<\/span>\nResult: pass\/fail per critical path<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          Playwright, Selenium, Cypress, Postman<\/span><\/p>\n<\/td>\n<\/tr>\n

          \n

          6<\/span><\/p>\n<\/td>\n

          		\n

          Equivalent under parallel \/ shadow run against live traffic<\/span><\/p>\n<\/td>\n

          		\n

          High + operational<\/span><\/p>\n<\/td>\n

          		\n

          Deterministic + Human<\/span><\/p>\n<\/td>\n

          		\n

          Correct against the workload you have today;<\/span>\nResult: divergence rate between old and new system on mirrored traffic<\/em><\/i><\/span><\/p>\n<\/td>\n

          		\n

          Traffic mirroring, blue\/green deployments<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          *Tokens are usually never free<\/span><\/span><\/p>\n

          The uncomfortable truth about reverse engineering is that you always have to start from scratch, because documentation cannot be executed, which makes it harder to implement good quality gates, but not impossible.<\/span><\/p>\n

          A check without a result is not a check<\/span><\/h2>\n

          The difference between determinism and non-determinism is the nature of the output. Deterministic checks produce a result and they also tell you if the result is actually good. Linting gives you a list of violations. A test run gives you pass or fail. Human (and AI) checks do not work like that. “Domain expert reviews the module” produces nothing, unless somebody decided upfront what should come out of it. And if nothing comes out, we are back at “looks good to me”.<\/span><\/p>\n

          So do not ask an expert to read 2500 words and tell you if it is correct. Give them the business rules the agent extracted and let them confirm or correct each one. The expert spends the same time, but the result is something you can act on.<\/span><\/p>\n

          And if a check cannot be broken down like that, then the check itself is the problem.<\/span><\/p>\n

          Closing<\/span><\/h2>\n

          Most teams I talk to are currently operating even below the bare minimum. If technical maturity and AI maturity are low, organizations prioritize investing resources into innovation projects. They learn the hard way what non-deterministic means, then they panic and demand people like me to fix it. Truth is I can’t. That decision needs to be made consciously. And that is work. Sometimes it is a lot of work. Balancing out risk and opportunity is always hard. Same as taking responsibility and ownership.<\/span><\/p>\n

          Pick your discipline. Take the conscious decisions and create your own validation layers. Apply them.<\/span><\/p>\n

          Only believe what you can validate. And validate.<\/em><\/i><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

          How to read this article This article picks up where my January piece left off. My catch phrase is still the same: “only believe what you can validate”. This article is about validation. If you are new to agentic AI (in modernization contexts), I would highly recommend reading The Realities of Application Modernization with Agentic […]<\/p>\n","protected":false},"author":172702,"featured_media":2383,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[35,1,38,91,92,109,89],"tags":[],"class_list":["post-2374","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agents","category-azure","category-app-development","category-migration","category-modernization","category-platform-engineering","category-thought-leadership"],"acf":[],"blog_post_summary":"

          How to read this article This article picks up where my January piece left off. My catch phrase is still the same: “only believe what you can validate”. This article is about validation. If you are new to agentic AI (in modernization contexts), I would highly recommend reading The Realities of Application Modernization with Agentic […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-json\/wp\/v2\/posts\/2374","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-json\/wp\/v2\/users\/172702"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-json\/wp\/v2\/comments?post=2374"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-json\/wp\/v2\/posts\/2374\/revisions"}],"predecessor-version":[{"id":2384,"href":"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-json\/wp\/v2\/posts\/2374\/revisions\/2384"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-json\/wp\/v2\/media\/2383"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-json\/wp\/v2\/media?parent=2374"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-json\/wp\/v2\/categories?post=2374"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-json\/wp\/v2\/tags?post=2374"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}