How to check AI-generated GIS, 3D and machine learning code before you trust it

AI assistants now write a surprising share of the code for mapping, 3D scenes and machine learning. The code is usually tidy, well commented and confident. It also quietly assumes things about your data that may not be true. The cost of a quiet mistake in this field can be high: an area measured in square degrees, an elevation model in the wrong height system, a model tested on data it has already seen.

This guide gives you a routine for checking AI-generated work, and a way of briefing the assistant that prevents many errors before they happen. It is the practical side of the idea running through this learning path: AI can build, and people are needed to develop, tune and contextualise.

Why AI code goes wrong in this field

• It does not know your data. It cannot see your coordinate system, units, sensor or no-data values unless you say so.
• It reaches for common defaults, which may be wrong for your region or task.
• It writes plausible code. A function that runs without error is not the same as one that is correct.
• It may mix up conventions, such as latitude and longitude order, or rows and columns.
• It can invent functions and options that do not exist in a library, or use outdated ones.

Step 1: brief the assistant properly

The quality of the code depends on the context you provide. Before asking for anything, write down the facts that matter.

• The coordinate reference system and units of each dataset.
• The sensor, bands, resolution, data type and no-data value.
• The shape and order of arrays, for example bands, rows, columns.
• The size of the data, so that it chooses approaches that fit in memory.
• The libraries and versions you use.
• What a correct answer looks like, with one example you already know.

Then ask the assistant to list every assumption it is making, and to explain why. Read that list first. Wrong assumptions are easy to spot when they are written down.

Step 2: the ten-point review

1. 01Units. Are lengths in metres, feet or degrees, and are angles in degrees or radians? Is any conversion explicit?
2. 02Coordinate systems. Does every layer share one system? Are measurements made in a suitable projected system, not in degrees?
3. 03Axis order. Is it latitude and longitude, or x and y? Are image rows treated as running downwards?
4. 04Array shape and dtype. Is it bands first or last? Integer division or overflow where floats are needed?
5. 05No-data. Are masked, missing and cloud pixels handled before statistics are computed?
6. 06Resampling. Nearest neighbour for classes, and bilinear or cubic for continuous values?
7. 07Data leakage. Does anything from the test set influence training, including through spatial neighbours or scaling computed on all the data?
8. 08Evaluation. Are the metrics suited to the problem, such as recall for rare events, and tested on separate areas?
9. 09Edge cases. What happens with empty inputs, a single pixel, the date line or very large values?
10. 10Libraries. Do the functions and arguments exist in your installed version? Are defaults suitable?

Step 3: test with known answers

The fastest way to find a mistake is to give the code a case whose answer you know.

• A distance between two points you can measure another way.
• A rotation of a point by 90 degrees, which must land on a different axis, with the same length.
• A small raster where you can compute the answer by hand.
• A polygon whose area you know, such as a one-hectare square.
• A model that must score near chance on random labels, and well on a trivially easy set.

Write these as small automatic tests, and run them whenever the code changes, including when you ask the assistant to modify it.

Step 4: compare with a trusted tool

For spatial work, a free desktop GIS makes an excellent referee. Load the input and the output, and check the position, the extent, the pixel size and the values. Measure a few features with the measuring tool. If a script’s output sits in the wrong place or has the wrong size, a GIS will show it in seconds.

Step 5: look at it

Plot or map the result. Many errors are glaringly obvious on a picture and invisible in numbers: flipped images, shifted layers, strips of missing data, stripes at tile edges, and a classification that follows terrain or shadows. Ask whether the picture agrees with what you know about the place.

A worked example: area in square degrees

You ask an assistant for code that computes the area of each field in a file of polygons. It reads the file and returns the polygon area for each feature. The numbers look small and reasonable, and the code runs cleanly.

• The check: you try it on a square you know covers one hectare. It reports a tiny number such as 0.0000011.
• The cause: the file is in latitude and longitude, so the area is in square degrees.
• The fix: reproject to a suitable projected system in metres before computing area, or use a geodesic area function.
• The lesson: the unit check and one known-answer test found in two minutes what could have misreported a district’s farmland.

Handle sensitive material carefully

• Do not paste secrets, passwords or personal data into an assistant.
• Check where your data goes when you share it with an online service.
• Read unfamiliar code before running it, particularly anything that deletes files, uses the network or installs software.
• Review licences when code resembles known open-source projects.

Keep a record

Write down what you asked, what the assistant produced, what you checked and what you changed. This short record helps when a result is questioned, helps colleagues reproduce the work and teaches you which kinds of mistakes your assistant makes most.

Who does what

• The assistant drafts, explains, translates and suggests alternatives.
• You define the problem, supply the context, test against reality and decide what is good enough.
• Your organisation sets the rules for data, review and accountability.

Frequently asked questions

Should I stop using AI for code?

No. Used with this routine, it speeds up good work. The aim is to combine its speed with your checking.

How much checking is enough?

Match the effort to the stakes. A quick sketch needs less than a map that will guide a decision about land, money or safety.

Can I ask the AI to check its own code?

It can find some problems, and writing tests is a good use of it. But it can share the same blind spots, so keep independent checks, such as known answers and a GIS.

What if I do not understand the code it wrote?

Ask it to explain line by line, simplify it or rewrite it more plainly. If you still cannot follow it, do not rely on it for important results.

The fundamentals are what make this routine work. Units, coordinate systems, statistics and the physics of your data tell you what to check and how to recognise a wrong answer. With them, AI becomes a powerful, trustworthy assistant. Without them, you are trusting a confident stranger.