1.1 The Wiles and Woes of Code

Anyone who has worked with scientific code – be it their own or that of others in their field – has likely experienced the frustration of trying to get that code to work as intended, if at all. Worse yet, you may even have found yourself perplexed by cases in which scripts that previously worked just fine suddenly throw errors when you attempt to revisit or reuse them. While such experiences may make you question your sanity (or your talent for programming), they are actually incredibly common.

Beyond the hours spent frustratingly inching your way towards a functional script, there is the additional concern of incorrect results, or results whose correctness is obscured by poor reproducibility and opaque code.

This is a risk that is not exclusive to trainees and students. Even experts with years of programming experience can fall into the trap of writing – and even publishing – code whose results are irreproducible:

2.2 One Step At A Time

In Python – and most modern programming languages – it is generally better to be explicit rather than implicit, meaning that you should try to transparently communicate your structure and your operations. For example, consider the line in which we define the maximum intensity projection:

z_index = 2
xyz_order = (1, 2, 0)
maximum_intensity_projection = np.max(np.transpose(nd2_file, xyz_order), z_index)

If you are not familiar with the operation the microscopy data is being subjected to,  you could be confused as to what exactly is happening in the implicit processing step – or not realize that one is occurring at all.

In order to communicate both the existence and the purpose of this additional processing step to readers of our code, we need render it explicit by separating it out and assigning its result a variable name of its own:

nd2_file = ND2Reader('20191010_tail_01.nd2')

z_index = 2
xyz_order = (1, 2, 0)
xyz_img = np.transpose(nd2_file, xyz_order)
maximum_intensity_projection = np.max(xyz_img, axis=z_index)

minimum_pixel_value = np.min(maximum_intensity_projection)
maximum_pixel_value = np.max(maximum_intensity_projection)
pixel_value_range = maximum_pixel_value - minimum_pixel_value
normalized_img = (maximum_intensity_projection - minimum_pixel_value) / pixel_value_range

downsampling_factor = (1, 1)
downsampled_img = zoom(normalized_img, downsampling_factor)

smoothing_factor = 0.02
smoothed_img = gaussian_filter(downsampled_img, sigma=smoothing_factor)

Now anyone who reads this script should be able to understand that the data is being normalized prior to computing the maximum intensity projection, regardless of whether they recognize the normalization equation or not.

Making steps embedded in a separate operation more explicit is also a tool in your communication kit: It’s a way to highlight a particular nuance of your code and draw the attention of anyone reading it to what you are doing.

There is, of course, some level of negotiation between giving every single operation a line of its own and keeping the logical steps your code takes explicit. Generally speaking, you will want to make explicit every step which transforms data in a significant way, and which could affect logic down the road.

For example, normalizing the data means that what was previously an array of values between 0 and 65,535 (the maximum value of a 16 bit pixel) is now an array whose values fall between 0 and 1. That could have a significant impact on downstream processing, so it’s important that users realize that this is happening.

Looking at our example, you may also notice that we did not separate out the definition of the dividend and the divisor:

minimum_pixel_value = np.min(maximum_intensity_projection)
maximum_pixel_value = np.max(maximum_intensity_projection)
pixel_value_range = maximum_pixel_value - minimum_pixel_value
normalized_img = (maximum_intensity_projection - minimum_pixel_value) / pixel_value_range

This, too, is an exercise in communication, because it preserves the actual equation we’re using for normalization in a single line. Writing your code with this approach in mind – that is, defining the individual components of equations, but keeping the equations themselves legible and recognizable – allows subject matter experts to quickly review the math underlying your code.

2.3 Keep It Short And Simple

It is a common misconception among new coders that clever code is concise. To an extent, that can be true. You can shorten your code through the use of intelligent structure. However, the kinds of scripts that tend to be written early on in your programming journey are far likelier to suffer from being excessively convoluted and broadly undisciplined.

As a novice programmer, it’s important not to confuse brevity for elegance. When writing code, try to strike a balance between simplicity and clarity. Stuffing as much logic as possible into a few lines of code can sacrifice logical clarity and human readability, which is ultimately counterproductive.

2.4 Working with Artificial Intelligence

With the rise and rapid development of large language models, the use of artificial intelligence in programming has undeniably become commonplace. This introduces a number of fantastic advantages, and responsible use of AI can increase both the quantity and the quality of your code.

If you’ve used LLMs to generate, edit, or augment your work, then you’ve no doubt encountered cases in which it made both obvious and subtle mistakes. Thus, as with any tool, you need to know how to use AI – and just as importantly, how to not use it – in order to ensure that its impact remains net positive.

Examples of good uses of AI-assisted coding would be syntax completion, or adjusting or polishing plotting routines: The code you use to generate your figures is usually boilerplate, easy to double-check for correctness, and used to illustrate your results rather than define them. Similarly, certain front-end tasks, such as generating a simple documentation page, are largely trivial, relatively easy to inspect and test, and unlikely to result in publishing incorrect findings.

AI can also be a good sounding board that you can use to help you generate and interrogate ideas. It can tell you about useful libraries you might not have known about, highlight common implementation strategies, or outline some of the steps that are likely to be involved in your prospective project’s development process. LLMs are a good resource for interrogating some of your own blind spots and greasing the mental wheels – but you need to be careful that it does not replace those wheels altogether. This is all the more important if you’re a novice programmer, because thinking through computational problems and devising programmatic solutions is a skill that is developed through practice.

These are precisely the risks that you run when you use AI to accomplish complex tasks like designing algorithms, implementing deeply embedded components of complicated systems, or writing performance-critical routines. These are all things that AI isn’t equipped to handle, because such tasks rely on many different moving parts both scientifically and programmatically, and understanding and reasoning about them requires both expert knowledge and experience applying it.

Another issue you’ve probably seen is that commercial LLMs tend to be better at performing like an expert than actually being one (even in the latest updates). 

The work they produce could look convincing and even produce functional programs, but feature mistakes or nuanced functionalities that the untrained eye could miss.

A 2024 study by Perry, Srivastava, Kumar, & Boneh found that users that use AI assistants tend to be more confident in the quality of their code (in this case, its security), even though it was actually significantly less secure than code written without the use of AI assistants. The higher vulnerability of AI generated code is well documented in LLM literature.

This is further complicated by the fact that AI code generation often involves some degree of back-and-forth between the AI and its users, throughout which the generated code is iterated upon. This is a problem because that iteration isn’t necessarily resulting in more robust code – for example, in a preprint posted in May of 2025, researchers found that code that had been iterated upon tended to degrade in its security. The preprint found that this effect could be mitigated with mindful prompting that prioritized code quality over features, but not only did degradation occur even in prompts that were written with a focus on security, iterations involving such prompts were actually more likely to introduce certain types of errors than their more feature-focused counterparts. 

So the risks of using artificial intelligence to generate code not only remain, but they may even be exacerbated by iterative generation and targeted prompt engineering. There is no way to immunize your AI-assisted code against these risks except to:

1. Limit your use of AI to idea generation and simple, transparent tasks.
2. Avoid outsourcing actual thinking and decision-making to AI.
3. Always use robust human validation.

There will be more to say about the responsible integration of artificial intelligence in scientific programming as this unit proceeds and we cover different aspects of code design, so be sure to keep an eye out for AI-specific sections in upcoming lessons.