Credit: gorodenkoff/iStock via Getty
Until just a few years ago, my journey in learning to code as a wet-lab clinician-scientist was marked by frustration. I regularly found myself staring at a flashing cursor, scouring jargon-filled forums for clues to why my script had crashed and spending hours hunting down a single missing comma or mismatched bracket. For scientists whose work bridges the gap between experimental observation and computational analysis, the barrier to entry was steep.
The release of advanced large language models (LLMs) and autonomous artificial-intelligence agents has since completely changed the situation. Now, anyone can prompt an AI model to construct complex computational pipelines that would otherwise require days or weeks of troubleshooting, and more patience than any researcher could reasonably be expected to have. This begs the question: if AI can generate these complex statistical analyses and bespoke data visualizations in seconds, do you still need to learn to code?
The answer, to my mind, is an emphatic ‘yes’. But the way we learn must change. The bottleneck is no longer mastering coding grammar and syntax; it is learning how best to prompt and guide AI tools to answer our scientific questions. In many ways, early-career scientists are now stepping straight into roles historically reserved for senior software engineers: supervising, critiquing and refining output generated by others, or, in this case, an automated assistant.
Here are six tips to help get the most out of the process.
Think like a systems architect
When I started using AI to help me code, I worried that I would quickly lose the skills I had developed. I had spent years learning how different functions could be used to merge data sets, generate figures and run statistical analyses. Using AI felt like cheating, even if the answers to my problems were already available online and LLMs were simply quicker at finding them.
Eventually, I realized I didn’t need to remember the exact syntax required to run a hierarchical clustering algorithm or pivot a table using Python’s pandas library (a collection of data-analysis tools in the Python coding language). I simply needed to know that these methods existed, roughly how they worked and when best to use them. By reading the function documentation, I learnt what different functions could do, but using AI meant I didn’t have to worry about exactly how to make them do it.
By thinking like a systems architect, I could direct the AI system towards robust, reproducible solutions without getting bogged down in syntactic minutiae.
Think modular
When you have an AI model capable of writing hundreds of lines of code instantly, the temptation is to ask for a miracle: a single monolithic script that ingests your raw data, cleans them, runs the statistics and outputs a formatted figure for publication.
I quickly found that this was a fragile and fundamentally flawed approach. Monolithic scripts are a nightmare to troubleshoot. If a single variable changes, or if the AI system hallucinates a step midway through the analysis, the entire architecture collapses, leaving you to sift through a wall of code in search of the error.
Instead, I embraced modular programming. I prompted my LLMs to write small, discrete, single-purpose functions — for instance, one to ingest and format raw data, another to normalize their values and a third to generate a visual representation of the data.
Pipelines built from such self-contained blocks of code are easier to debug than are their monolithic counterparts. If a specific transformation fails or an error occurs, I can isolate, interrogate and fix the faulty function without jeopardizing the rest of the pipeline. And because the code blocks are modular, I can reuse them across projects. In this way, I have seeded a personal library of trusted, AI-generated tools.
Embrace standardized structures
Because AI reduced the friction of writing code, I found myself generating scripts, code iterations and data outputs faster than ever before. Inevitably, my project directories quickly devolved into an unnavigable mess of files with names such as analysis_final_v3_really_final.py.
Worse, I realized that, during one project, I had accidentally overwritten my raw data files (luckily, I had a backup). Through this, I learnt the importance of good data-project organization — a practice that is embedded in resources such as the Cookiecutter Data Science framework.
Adoption of a specific framework to compartmentalize projects is no longer just best practice for coding, but a necessity in the AI era. It mandates a rigid separation between input files and analytical scripts. For example, a standard Cookiecutter structure dictates that all raw, primary data (such as sequencing files or clinical spreadsheets) are kept in one folder that is strictly read-only. Active analysis scripts are kept in another, and all outputs are funnelled into a third folder. By enforcing this structure, I no longer worry that an AI-generated script will accidentally overwrite or corrupt my primary data sets.
Maintain privacy
The integration of AI into scientific workflows introduces significant ethical and regulatory vulnerabilities. Public models are often trained on user inputs, meaning that if one user feeds sensitive patient data into a public, cloud-based LLM, those data could theoretically be regurgitated to another user somewhere else.
To mitigate that risk, I learnt to generate ‘dummy data’. Before asking an AI system to write an analysis script, I provide it with the column headers, expected data types (for example, integers, strings or floating-point numbers) and the dimensions of my data table, while explicitly ensuring that no real values are shared (see ‘Example AI prompts’).
I then ask the model to write, test and debug analytical code using this fictional data set, which is structurally identical to the real one. Once the code is working, I can copy it into my secure, local environment and use it with my real, protected data. The LLM never sees the sensitive information, and data protection remains intact.