This is the fifth post in my series about working with an AI coding assistant. The earlier posts covered getting started, observations, rules, and practical results. This one is about something I keep coming back to: communication.

Det som är dunkelt sagt är dunkelt tänkt

A guy I studied with some 30 years ago told me a Swedish saying: "Det som är dunkelt sagt är dunkelt tänkt." What is obscurely said is obscurely thought. It has stayed with me ever since. I can vouch for it. People who can't be clear are too often not concrete enough for me to understand the details.

I have noticed this while working with my coding assistant. Half-formed prompts produce bad results. If I leave out context or describe a problem in circles, the assistant doesn't ask for clarification. It guesses. And the guess is often wrong.

The same thing happens with colleagues. They are just more polite about it. A senior developer will eventually say "I don't follow, what are you actually trying to solve?" The assistant just runs with whatever you gave it.

Communication as a prerequisite

People who can't communicate clearly won't get good results from a coding assistant. It can't read your mind. If you can't finish your sentence, neither can it.

I have seen this with myself. When I take the time to write a clear issue or a clear prompt, the results are dramatically better. When I'm sloppy, I get slop back. The tool amplifies whatever I put in.

If I say "fix it" without details, the result is unpredictable. Sometimes the assistant gets lucky and goes in a good direction. Sometimes it goes somewhere random. It is about as predictable as saying "build the system I'm thinking of but not telling you about." You get something. But not the thing your clients pay you to understand and build.

The developer is the key here. Without the developer understanding what the client meant, not just what the client said, anything can be built. And will be built. But it won't solve the client's actual problem. That has always been true. The assistant makes it more obvious because it does exactly what you tell it, quickly and without questioning. A misunderstanding that used to take a week to build now takes an hour. You find out faster that you built the wrong thing.

That translation, from what the client says to what the client actually needs, is why we will need developers for the foreseeable future. I'd say at least the next 10 to 15 years. After that I'm retired and it becomes a Somebody Else's Problem.

You have seen this before

Every few decades a new tool comes along and some people resist it. The pattern is always the same.

Accountants got calculators. The skill shifted from doing arithmetic to making judgments about the numbers. The Swedish company Facit was the world leader in mechanical calculators with 14,000 employees. When electronic calculators arrived from Japan in 1971, Facit couldn't adapt. All their expertise was in mechanics, not electronics. They went from market leader to bankrupt in about a year. Writers got word processors and some insisted the craft was in the typewriter. Architects got CAD and photographers got digital cameras. Both were accused of cheating. Sailors got GPS and the ones who stuck with celestial navigation got left behind. We haven't seen them for a long time. I hope they didn't drown, but no one except them knows.

Closer to home, programmers got IDEs with auto complete. I have seen architects in 2010 still using Emacs with their own homegrown extensions, struggling to actually get things done. Stack Overflow made it OK to look things up, and nobody seriously argues against version control any more.

There is also the story of Semmelweis, who figured out that doctors should wash their hands between patients. They were carrying infections from autopsies straight into the maternity ward. Women were dying because of it. Semmelweis showed that handwashing reduced mortality dramatically. His colleagues resisted anyway. Not because the evidence was weak, but because accepting it meant admitting they had been killing their patients. The resistance was about ego, not logic. It was unfortunate for a lot of women.

The world moves on

Coding assistants are here. They are not perfect and they need supervision. But they are getting better, and the developers who learn to work with them are getting faster.

I worry about the developers who actively resist these tools. They will fall behind and struggle to make a living as developers. They will suffer.

I also worry about us pulling up the ladder behind us. The threshold for developers who just got their degree and need their first job is getting too high. In ten years we may be short of senior developers because no one was willing to hire the juniors.

I don't have a solution. I would hire a junior myself if I could, but right now I don't have the funds or the paying customers for it.

Resources