Code and translation

Two text capabilities deserve their own discussion: code and translation. Both are tasks where the model produces output very quickly. Both are tasks where the output, on a quick read, looks correct. And both are tasks where the cost of a hidden error can be very large.

This section is about using them well — which means using them with the discipline of verification.

Code

You do not need to be a programmer to read this section. The lessons are general: they apply equally to using AI for a programming task, a spreadsheet formula, an SQL query, or a complex Excel macro.

What models do well in 2026:

• Writing boilerplate code — repetitive patterns, common templates, standard data processing.
• Translating between programming languages and frameworks.
• Explaining what unfamiliar code does, line by line.
• Generating unit tests for existing code.
• Debugging error messages — paste in the error and the surrounding code, and the model is often right about the cause.
• Refactoring small functions into cleaner versions.

Where models break:

• Anything that requires understanding the larger system the code lives in — interactions across files, organisational conventions, deployment context.
• Subtle correctness — code that compiles, looks reasonable, and is wrong in a way that only careful reading reveals.
• Security-sensitive code — authentication, encryption, data validation. Confident-but-wrong here is dangerous.
• Up-to-date library versions — the model’s knowledge may be a year out of date, and the code it writes may use deprecated APIs.

The cardinal rule, which applies whether you write code or commission it from a model: run it, test it, read it before trusting it. “It compiled” is not the same as “it’s right.”

A workflow for non-programmers using AI for code

If you don’t program but want to use AI for an automation task, follow this pattern:

1. Describe the goal in business terms. “I have a folder of 200 PDF invoices. I want a CSV with vendor, date, amount, currency for each.” Don’t try to specify implementation.
2. Ask the model to lay out the steps first, in plain English. This is your sanity check.
3. Ask for the code only after you understand the steps.
4. Run on a sample of 2–3 files before running on all 200. You’ll catch the cases where the model misunderstood your data.
5. Spot-check the output. If 5 random rows look right, the rest probably do too.

This pattern lets non-programmers do automation tasks that would have required a developer five years ago — without the failure mode of trusting code you can’t read.

Translation

Translation is the area where models have most clearly outperformed older tools. A 2026 frontier model translating between Nepali and English produces output that, for most uses, is indistinguishable from professional human translation. For technical documents, sometimes better.

But “for most uses” is doing work in that sentence. Let’s be specific about when to verify.

Use without much verification when:

• The translation is for your understanding. Asking the model what a Nepali government notice says, in English, so you can act on it.
• The original and translated language are both well-resourced (English, Nepali, Hindi, common European languages).
• The text is general-purpose — news, casual correspondence, conversational.
• The cost of a small error is low.

Verify carefully when:

• The translation is outgoing — going to a client, a government, the public.
• The text contains specific values: dates, numbers, names, legal terms, technical vocabulary. Models occasionally substitute or paraphrase these.
• Either language is low-resource — Maithili, Tharu, Limbu, etc. Quality drops sharply.
• Tone or register matters — formal Nepali vs. colloquial vs. honorific can shift in translation.

Verify and have a human review when:

• The text is legal, medical, financial, or government-binding.
• The text will be published or attributed.
• Mistakes will be expensive — damage reputation, lose money, cause confusion.

Specific Nepali translation patterns

Three patterns that come up often:

1. English-to-Nepali outbound correspondence. Models are excellent. Specify the level of formality you want (formal, business, casual). Specify the relationship (subordinate writing to senior, peer to peer, business to client).

2. Nepali-to-English of government notices and legal text. Good at gist; verify dates, numbers, and proper nouns. Models will sometimes invent a plausible English translation for a specific legal term that doesn’t quite match the official one. For anything that will guide a decision, cross-check.

3. Code-switched text (Nepali with embedded English words or vice versa). Modern frontier models handle this naturally. Dedicated translation tools (Google Translate) sometimes mishandle it. Use a generative model.

What translation tools cannot give you

Two limits worth knowing:

Cultural context. A model can translate the words, but cannot decide whether the result is culturally appropriate. A Nepali invitation card translated literally to English might miss the customary flourishes; an English business letter translated literally to Nepali might come across as cold. For published material, a human review remains essential.

Confidential material. Most translation services — including the major model providers — log your input. If you are translating confidential business material, government documents, or personal data, use a tool with explicit privacy guarantees, or use a model that runs on your own hardware. We return to this in Chapter 6.

A combined example

Suppose you are an analyst at a small Nepali NGO. You receive a 12-page English report about agricultural practices from an international partner. You need:

1. A clear English summary for your director.
2. A Nepali version of the summary for the field team.
3. A list of recommendations in a table.
4. A script to email the summary to a list of 30 partners.

A reasonable pipeline:

• Step 1. Paste the 12-page report into a model. Ask for a one-page English summary with page citations.
• Step 2. Ask the same model to translate the summary into Nepali, specifying tone (professional, accessible).
• Step 3. Ask the model to extract the recommendations as a table.
• Step 4. Ask the model to write a small Python script that takes a CSV of partners and sends the summary via email.
• Step 5. Verify: spot-check 3 claims in the summary against the source; have a Nepali-speaking colleague glance at the translation; test the script on 2 of your own email addresses before sending.

What would have been a half-day’s work is now an hour, of which 30 minutes is verification. The verification is not optional. It is what separates competent AI-augmented work from carelessness.

Check your understanding

Quick check

—

When using a generative model to write code, the most important habit is:

1. AAlways use the most expensive model available
2. BAlways read the code and test it on a small sample before trusting it on the real input
3. CNever edit the code yourself
4. DAsk the model the same question three times to be sure

Check answer→

What comes next

We’ve covered the major text tasks. Chapter 4 moves to a very different modality — images, audio, video — where the prompting skills are similar but the failure modes are entirely different. We’ll see what these tools can produce, what they cannot, and the workflows that work in 2026.