By Parameswara Reddy Venna (Paramesh Venna), Senior Manager, Statistical Programming, Ephicacy Consulting Group

Any programmer who’s been at this long enough will know that code can run without any errors and still be wrong. It compiles and produces output, the log looks clean, yet it may not be doing what’s needed for the study or analysis. That’s the first thing that comes to mind whenever generative AI comes up. AI-generated code can look clean and feel structurally right, but still miss what’s required for the study. In this post, I want to explain where I’ve found these AI tools useful, where I think we need to slow down, and why human review still matters.

Where generative AI can help

Understanding a piece of legacy code which I didn’t write is probably the hardest part in my programming experience, and many others may have had a similar experience. AI can provide a plain-language walkthrough in a few seconds and suggest possible issues to investigate. Writing up program headers isn’t the most exciting part of the job, and a first draft to edit saves real time. It’s also been useful for troubleshooting. For example, when a human eye misses exactly what’s causing an error or warning in the log, AI can act as a second pair of eyes and help identify the root cause. All this doesn’t mean my code is more accurate. Accuracy still depends on my understanding of the requirements and whether the code correctly implements them.

Where we need to be careful

One might assume that giving an AI tool access to the protocol and SAP would enable it to fully understand a study. I don’t think it’s that simple. Having access to a document is different from interpreting it. Protocols and SAPs are often ambiguous, and rely on established conventions an experienced programmer can pick up from context rather than the text itself. They’re also amended under version control as a study progresses, with the SAP finalised before database lock. An AI tool can read the document and still apply the wrong interpretation, miss which version governs a point, or lack context outside the document, such as a sponsor clarification, a decision from meeting minutes, or a team’s programming convention. Reading a document is the easy part. Deciding what it means for a specific edge case is arguably the harder part of the job.

Handling unscheduled visits is a good example. An SAP may define scheduled visit windows, but in collected data may not fit within them. Since specifications are usually developed before real-world data patterns are known, the SAP often doesn’t spell out how to handle these special cases. Should it be retained without an analysis visit assignment, be assigned to a scheduled visit under a documented rule, or excluded from a specific analysis? Until that decision is made, there is nothing written down for an AI tool to apply. It should be documented in an analysis specification, sponsor clarification, or decision log. The documented rule should then be applied consistently rather than left to individual interpretation. The programmer’s role is to recognise such cases, apply existing conventions, and escalate for a documented decision when they don’t.

What the evidence shows

A 2025 study presented at USENIX Security tested 16 different LLMs across 576,000 code generations and measured package hallucinations – cases where AI-generated code referenced software packages or libraries that don’t exist. The average percentage of hallucinated packages was at least 5.2% for commercial models and more than 21% for open-source models. I want to be clear that this study examined general software development, not SAS, SDTM, or ADaM programming, and it did not evaluate clinical derivation logic. However, it establishes a failure pattern worth watching. AI-generated code can look syntactically valid and completely plausible while still referencing a dependency that doesn’t exist, although this would normally be detected when the package is installed, imported or executed. A clinical derivation can pass a casual review in a similar way, looking completely correct while being wrong for an entirely different reason, such as a misapplied protocol rule rather than a nonexistent package.

The regulatory perspective

FDA’s January 2025 draft guidance outlines a risk-based framework for assessing the credibility of AI models used to generate information supporting regulatory decisions about a drug’s safety, effectiveness or quality. It is not broad guidance on how to use AI in clinical programming. The level of scrutiny depends on the model’s context of use and associated risk, not how much AI-generated material appears in submission. The EMA has taken a similar stance in its reflection paper, emphasising a human-centric approach and the importance of ensuring that AI output is fit for purpose. As I read it, both agencies are pointing to the same underlying idea: the tool itself doesn’t carry the accountability. The people and organisations using it do.

A practical way to use these tools

I consider AI-generated code an early draft that needs to be reviewed carefully, never the final answer. In practice, the process is straightforward: define the task clearly, let AI generate a first draft, verify it against the actual requirements, and test both normal cases and the edge cases that could cause problems. A documentation trail should be maintained the same way it would for any other deliverable, regardless of who or what created the first version.

The person using an AI tool remains responsible for following their organisation’s policies and reviewing its output. Provide only the information needed for the task, and never enter patient-level data, confidential sponsor information, or proprietary materials unless the tool and intended use have been specifically approved. None of this is really a new process. It follows the same validation and documentation practices used for other programming deliverables. Generative AI simply adds a new step upstream – the first draft – which requires the same level of scrutiny as anything else.

Human review still matters

In the future, I strongly believe generative AI is going to be an important part of many programmers’ day-to-day work. I don’t see it replacing statistical programmers anytime soon, but it will be an extra hand that can speed things up when used properly. It comes down to what happens after AI produces a draft: the programmer must decide whether the output meets the requirements. That’s not a smaller role. If anything, it’s the part of the job that was always the hardest to automate, and it’s the part that protects the integrity of a submission. Whatever tools we use for work, the interpretation, the correctness decisions, and the accountability for the final output are still ours.