Two Maps From One Line — What AI Can and Cannot Do at Work

Whether you can build it is no longer the question. Who checks whether what you built is correct — that is the question.

Last weekend we built two maps. One shows where in Seoul you can actually see the fireworks festival. The other shows when and where autumn flowers peak across Korea.

Each request was one line.

This article is not about showing off the result. What we wanted to know was different. Can this way of working move into a company, and if so, how far? We built both to find that boundary.

What we built

The first is a viewing-spot map. The request was one line: "Use a map of Seoul and elevation data to show where the fireworks are visible, as a heatmap." Forty minutes later we had a map that had calculated line of sight for 990,000 cells, each 30 meters square.

The second is an autumn flower map. We asked it to "put on a map when and where to go to see a given plant." It gathered peak timing for 62 locations nationwide and laid them on a time axis. Move the date and only the places blooming then light up.

Both are public. The making of each is written up in the fireworks map post and the autumn flower map post.

Why this did not work before

A few years ago the same job would have stalled in two places.

First, we did not know the data existed. Global elevation data from the European Space Agency, building-height data from the European Commission, autumn foliage forecasts from the Korea Forest Service. All free and public — but you have to know they exist to look for them. For a long time this was the real bottleneck.

Second, breaking open the formats took days. Satellite data comes in unfamiliar file formats and unfamiliar coordinate systems. Installing the specialist tools and learning them is days of work on its own.

Both now take minutes. But the bottleneck did not disappear. It moved.

The new bottleneck is verification

Partway through, this happened.

We pulled elevation data and checked it. The site of Parc1 in Yeouido came back as 13 meters. There is a 333-meter tower standing there. We switched to a different dataset and the 63 Building came back as 18 meters.

The reason was simple. Global elevation datasets are mostly built to measure the ground, so buildings are stripped out as noise. That is correct for geological survey or flood modeling, and exactly wrong for asking whether a line of sight is clear in a city.

Here is the part that matters: the data did not throw an error. The format was valid, the coordinates were right, the numbers were all there. Had we simply calculated, the map would have finished without complaint. It would have been a wrong map, and most likely nobody would have noticed.

Output that only looks right is the real danger

This is what we most want to convey.

The risk in AI output is not the absurd answer. Absurd answers get caught. The danger is output with a credible shape. If it looks like a map, people believe it is a map. If it arrives as a report with tables and figures, people believe it was verified.

In an organization the problem compounds. As a working-level document moves up the reporting chain, fewer and fewer people trace where the numbers came from. The further up it goes, the more certain it looks.

So we would put it this way. AI adoption succeeds or fails not on what you can build, but on whether you built a way to check that it is right.

What works and what does not

Building both made the boundary fairly clear.

Works today	Still hard
One-off analysis that combines public data	Production systems that must keep running
Opening up material that formats had locked away	Business judgment without internal data
Gathering the evidence for a decision	Automatic decisions with nobody to verify them
Prototypes built before you commit to building	Accountable domains under regulation or safety rules

The left column is work you can undo and where someone will check. The right column is work you cannot undo, or where being wrong passes unnoticed.

Production systems in particular: building and maintaining are entirely different jobs. What took 40 minutes to build takes 40 minutes to fix — but whether anyone will own that code when it breaks in six months is a separate question. We covered this in one year with AI agents.

Four things that worked in practice

State the goal and the shape of the result together. The first request contained both a goal, where it is visible, and a form, as a heatmap. Ask only for the goal and you get a table. Ask only for the form and you get something pretty and useless.

Do not name the dataset. Demand the source instead. A machine knows more than you do about which public datasets exist. Had we pointed at one specific dataset, the buildings would have stayed missing. Instead, asking where a number came from brings the source along with it. The Forest Service forecast surfaced in the second map exactly because of that question.

When a result looks off, ask to see the reasoning. When Namsan came back as a zero score, asking to see why pulled out two calculation errors. Skip that question and you keep the wrong map.

Ask for the limits first. Ask what in this result should not be trusted. If no answer comes back, the result is not finished.

What it costs

Most of the cost here is not staff time but tokens, and it rises with how much material gets read and how many times the work is revisited. We covered why quotes and actual bills diverge in what AI actually costs.

One thing to add: the more revisiting a job needs, the more it costs. But cut the revisiting and you get the plausible garbage described above. Verification cost is closer to something you accept than something you optimize away.

Closing

People call this kind of work one-click. Having done it, we found the phrase means something slightly different.

It does not mean there is less work. It means fewer human hands move. The judgment that used to sit in between did not disappear; it moved to the machine — and to the same degree, the job of checking whether that judgment was right became new work for people.

If you are evaluating AI adoption and only ask what can be automated, you are seeing half of it. The other half is who notices, and when, if the result is wrong. That is what two maps taught us.

If your staff are already using AI on their own, setting up that verification step becomes more urgent. We covered that in your employees are already using AI.