Table of Contents
AI and Coding Jobs: The Translation Industry’s Brutal Warning
Arguments about AI and coding jobs tend to collapse into two familiar camps. One insists that software developers are safe because programming requires creativity, systems thinking, and an understanding of messy business needs. The other sees every new coding assistant as proof that the profession is about to disappear. Neither position is especially useful on its own.
The translation industry offers a more concrete warning. It shows what can happen when a technology does not need to be perfect to change the market for skilled work. It only has to become good enough that clients accept a lower-cost, faster alternative for a meaningful share of tasks.
Translation, like programming, was long treated as a high-barrier profession. It demanded years of study, cultural awareness, subject knowledge, and genuine fluency in at least two languages. A translator was not simply swapping words between columns; the job involved intent, tone, context, and the countless small decisions that keep a sentence from sounding mechanical or misleading. Agencies paid well, and freelancers could build stable careers around that expertise.
Then neural machine translation, supercharged by large language models, became surprisingly capable. The economics shifted quickly. Rates dropped. Gig volume fell. Translators who had built freelance businesses found themselves competing with AI-assisted output that clients could get for a fraction of the price. Wired has documented how AI is reshaping the translation profession, including the far less glamorous reality behind broad claims of productivity: fewer assignments, lower pricing power, and work that increasingly resembles reviewing a machine’s first draft.
That last point matters for developers. The first impact of AI is not always the total removal of a job. Often it is the removal of the most billable parts of it. If a client believes a tool can produce an acceptable first pass, the human may be asked to check, repair, and take responsibility for that output instead of creating it from scratch. The work remains, but its perceived value can change.
Programming is not translation, and pretending otherwise would be lazy. Code has to run. It has to fit an existing system, respect security and operational constraints, and survive future changes. A mistranslated sentence may be awkward; a flawed deployment or incorrect piece of business logic can create a much larger problem. Developers also work in teams, negotiate requirements, investigate failures, and make trade-offs that are rarely visible in a prompt.
But the overlap is real enough to make the comparison uncomfortable. Both professions have a large body of work that is expressed in language. Both involve patterns that can be learned from examples. Both contain routine tasks alongside difficult judgment calls. And in both cases, clients may not pay for the distinction between “excellent” and “adequate” when adequate arrives much faster.
The practical question is not whether AI can replace every developer. It plainly does not need to do that to alter hiring, contracting, and expectations around output. A team that uses AI tools to move faster may take on less routine work from outside contractors. A junior developer may face a different entry path if the tasks once used to teach basic professional habits are increasingly delegated to a tool. A senior developer may spend more time evaluating generated code, setting direction, and owning outcomes when the generated code is wrong.
That is a change in the shape of the job, not a reason to dismiss the job itself.
One Developer’s Experiment Tells the Whole Story
César Romero, a software developer and author, offers a useful small-scale example. He recently set out to translate his book Street-Smart Coding into Spanish. As a native Spanish speaker, Romero could have done the translation himself. Instead, he ran an experiment using GitHub Copilot and a carefully written prompt.
That prompt did not merely ask for a translation. It specified tone, voice, regional vocabulary, Latin American Spanish rather than Castilian, and stylistic preferences. In other words, Romero gave the system the kind of guidance that separates a generic request from a real editorial brief.
By his own account, the result was startling: Copilot translated entire chapters with almost no corrections required. For a book aimed at developers and covering technical concepts alongside professional advice, that is a meaningful benchmark. This was not a simple legal document or a product description. It was prose intended to teach and persuade, with personality built into the writing.
The lesson is not that translation expertise suddenly has no value. Romero’s experiment depended on someone who knew the source material, knew the target language, understood the audience, and could recognize whether the output met the brief. The machine produced a strong draft; the human still defined what “strong” meant.
That distinction maps closely to coding. An AI assistant can produce code that looks plausible, follows common conventions, and handles familiar workflows. It can also make an experienced developer faster when the developer knows what to ask for and how to inspect the answer. Yet a plausible answer is not the same as a correct one, and code review is not a ceremonial final step. It is where assumptions, edge cases, security concerns, and mismatches with the actual system tend to surface.
Romero also found a clear weak spot: idioms and domain-specific jargon. The English phrase “wear all hats,” meaning someone who handles every role on a team, was translated literally as “usar todos los sombreros,”
That small failure is revealing. Language models can reproduce patterns with impressive fluency, but fluency can disguise a missed meaning. Software has equivalent traps. A generated function may be syntactically tidy while misunderstanding an internal convention. It may solve the narrow request while ignoring the wider product rule that a human teammate would have learned through context. It may create a solution that works today but is difficult to maintain tomorrow.
What developers should take from the comparison
The reassuring version of this story is that judgment still matters. The less reassuring version is that judgment may become the part of the job clients expect developers to provide without necessarily paying for all the work that used to lead up to it.
Developers should therefore resist the idea that their long-term value rests on typing code faster than a machine. That was never the whole profession, even if interviews and job descriptions sometimes made it look that way. The durable work sits around the code: clarifying an ambiguous problem, understanding a customer’s real need, deciding what not to build, communicating risk, tracing a failure through a complex system, and taking responsibility for a decision after release.
Those skills are harder to automate because they require more than producing an answer. They require knowing which question matters, who is affected by the answer, and when a seemingly efficient shortcut will cause trouble later. This is why developers who invest in judgment, communication, and problem-solving will be far harder to automate away than those who do not.
The translation industry’s warning is not that skilled people become irrelevant overnight. It is that markets can reprice skilled work before a profession has agreed on what changed. Developers have time to adapt, but the sensible response is neither panic nor complacency. Learn the tools. Use them critically. Become the person who can tell when an answer is useful, when it is subtly wrong, and when the problem needs a human conversation before it needs another line of code.
