The Developer Who Needs a Translator

You can spot this one in about ten minutes. Ask a developer why a part of the system works the way it does. Watch what they do first. Some of them answer you. Others open the AI to find out, and you realise they're reading their own code for the first time.

That second person needs a translator. And once you need a translator, you need one everywhere.

A translator is fine for a holiday

Land in a country where you don't speak a word and a translator is a great deal. You order food, you find the hotel, you get through the week and go home. Nobody expects you to learn Japanese for five days.

Living there is a different arrangement. Now you need someone with you at the bank, at the clinic, at your kid's school, and in every meeting where a decision gets made about your life. You're in the room but you're not in the conversation. You're waiting to be told what just happened.

That's the position a developer is in when they accept AI code without reading it. They live in that codebase. They'll be in it every day for years. And every question about it has to go through the machine first.

You can't check a translation you can't read

This is the part that costs you money. If you don't speak the language, your translator is always right. Not because they are. Because you have no way to tell.

AI has the same problem with one extra twist. It sounds just as sure when it's wrong. The mistake comes back in clean code with sensible names and tidy comments, so it looks like something a good engineer wrote on a good morning. If the only check is "did it run", then anything that runs gets waved through. We wrote about that habit in it looks like it works, so they commit.

A developer who reads the code catches the wrong thing in about thirty seconds. Wrong tax rounding, a permission check on the screen but not on the endpoint behind it, a report that drops rows with no branch assigned. A developer who can't read it has one option, which is to run it and see if anything screams.

Ordering food is not signing a contract

Plenty of work is safe to hand over. A login screen, a table you can sort, a CSV export, a settings page. Get those slightly wrong and somebody notices in a day and it's a ten-minute fix. Use the machine hard on those. We do.

Then there's the other kind of work, where being ninety-five percent right is the same as being wrong. How your money moves. Who is allowed to see which customer. What happens when the bank confirms but your system doesn't. How you calculate the number that goes on an invoice with your company name on it.

You wouldn't sign a contract in a language you can't read because the guy next to you said it was standard. That's the same call a developer makes every time they accept a change to your billing logic without reading it.

The translator isn't in the room at 2am

Something goes down on a Saturday night. Orders are failing and the error message means nothing to anyone.

The AI will answer. It always answers. It'll give three fixes that all sound reasonable, and a developer who knows the system will pick the right one in a minute because they know which part of the code is under load and which change touched it last. Someone who can't read the code has no way to rank the three. So they try all of them. Each try is a deploy, and one of those tries makes it worse.

A one-hour incident becomes a weekend. Not because AI failed. Because there was nobody in the room who could judge the answer.

You never pick up the language

The worst thing about the arrangement is that it doesn't improve. A developer who reads what goes in is learning your business every week. After six months they know that Sabah branches invoice differently, that your biggest client always pays late and the system has to tolerate it, that one report is wrong on purpose because finance asked for it that way in 2023.

A developer who doesn't read is on day one, permanently. Two years in they're faster at pressing accept and no better at your business. Nothing accumulates. There's no memory to hand to the next person, which is why the handover doc reads like a Wikipedia article about software in general.

That memory is the thing that makes a five-year-old system cheap to change instead of scary to touch. It's also the thing nobody wants to pay to build any more, which we got into in nobody wants to train juniors.

What it looks like from your chair

You won't see any of this in the code. Here's how it shows up on your side of the desk.

The invoice for this arrives later as a rebuild quote. That road is mapped out in technical debt: the silent tax on your business.

"But reading it all would slow us down"

We hear this one a lot, and it assumes typing was the expensive part. It never was.

Reading two hundred lines properly takes maybe ten minutes. Untangling two hundred lines that nobody understood when they went in takes three days, and by then it's tangled with the four things built on top of it. You don't save the ten minutes. You just move them, and they get more expensive while they wait.

The fast teams aren't reading less. They generate a lot and reject a lot, and the rejecting is where their speed comes from.

Three questions that sort it out

You don't need to read code to run this check. Ask these in your next update, with laptops closed, and listen to what comes back.

None of these are gotchas. A team that reads its own work enjoys these questions and answers them in seconds. If the room goes quiet, the silence is your answer.

The honest version

We use AI on every project here and we're not going to pretend otherwise. It writes a lot of what we ship. The rule is that a person reads it, understands it, and can defend it in a year when somebody asks why the system does that.

Speaking the language of your own system is the whole job now. It always was, really, but you used to get it for free because you had to type every line to make it exist. That freebie is gone. Now understanding is a choice someone makes at the accept step, and plenty of people are choosing not to.

So ask your team to explain your system without opening anything. If they can, you're in good shape, whatever tools they use. If they can't, you don't have a development team. You have a translator on retainer, and a business you can't read.