#ai

I’ve been redesigning how agents interact with Codex, the Bible translation platform I work on, and I keep arriving at the same conclusion from different directions: the fewer tools you hand an agent, the more useful it becomes.

That sounds backwards. The instinct when you’re wiring an LLM up to your app is to give it a tool for everything — draft-cell, add-comment, flag-verse, assign-reviewer, one narrow function per feature, mirroring your UI one button at a time. I did this. It’s tempting because each tool is easy to write and easy to reason about in isolation. But a big tool list doesn’t compose. The agent has to guess which of forty near-synonymous actions you meant, the tools drift out of sync with the schema the moment someone ships a migration, and every new feature means another tool to write, document, and keep working. You end up maintaining two apps: the one your users touch and the one your agent touches, and they’re never quite the same shape.

What’s worked much better is collapsing almost everything down to a couple of general read and write tools, scoped to whatever permissions the calling user already has. The agent reads the state of a project the same way a human collaborator would, and writes to it the same way — no bespoke verb for every noun in the schema. If it needs to add a comment, it writes a comment record. If it needs to update a draft, it writes a draft record. The permission boundary does the safety work a narrow tool surface used to do, more reliably, because it’s the same boundary the rest of the app already respects. My rule of thumb these days: the fewer skills the better — that’s my life motto.

The same instinct showed up somewhere I didn’t expect: file import. Every translation partner who comes to Codex arrives with a different mess — some odd export from a decades-old tool, a spreadsheet with the columns in a different order than the last one, a zip of audio files with timestamps embedded in the filenames a different way each time. For a while I did what you’d expect: write a custom importer per partner, hand-map fields, ship it, wait for the next partner to show up with a format that didn’t fit any of my existing code. Individually reasonable, collectively absurd. Why would I build a custom importer for everybody — that’s so dumb. Nobody has time to maintain forty importers for forty file dialects that only exist because forty people exported data forty different ways.

So I stopped. Now the files just get dropped in, and an agent looks at them and writes the import logic on the fly, against the same general read/write primitives the rest of the system uses. It doesn’t need a parse-partner-x-format tool — just the raw files and a sense of what a well-formed record looks like on the other end. It can figure out the rest, which is exactly what I was doing by hand, just slower and with worse pattern recognition than a model that’s seen a thousand CSVs.

The moment this really clicked, though, came from a partner, not from my own code. He mentioned, almost in passing, that he’d basically stopped using the platform’s UI. Instead he tells his own agent: “you have the API key, solve this problem.” Whatever shape his data was in, whatever oddball task he needed done, he wasn’t waiting for a feature request to land on my roadmap — he was pointing an agent at the API and letting it write the one-off integration itself.

That reframed the importer problem for me. I’d been treating “build a custom importer per partner” as the cost of doing business, when the fix was to stop being the one who has to write the importer at all. If the app exposes its primitives — read, write, the actual shape of the data — over an API, then each partner’s own agent can write its own integration code, on demand, for exactly the file format it happens to have that day. Funnily enough, I’d already done the equivalent of this the same day, for a genuinely strange batch of audio, timestamps, and transcription files that didn’t map onto any importer I’d built — I just pointed an agent at the primitives and let it sort out the mapping. As long as the primitives are there in the app, if you can just point your agent at it and have it do stuff, that would be super cool. It already is.

There’s a broader shift underneath this that isn’t specific to translation tooling at all. A well-understood, genuinely low-complexity integration — say, auto-syncing translation progress to a partner’s own project-tracking board — used to sit in the backlog forever. Not because it was hard, exactly, but because “hard” was never the real constraint; the constraint was that it was tedious, one-off, and not obviously worth a sprint against everything else competing for the same week. A year ago I’d have said no to this integration. Today it’s an afternoon, because I’m not the one writing the glue code line by line — I’m reviewing what an agent wrote against primitives that already existed.

That’s the pattern I keep running into, in multi-agent translation and swarm-translation and everywhere else I’ve experimented with multi-agent setups: the leverage isn’t in building smarter individual tools, it’s in building fewer, more general ones and trusting an agent — the app’s, or increasingly, the partner’s own — to compose them into whatever the moment requires. The bespoke integration business was never a good business to be in. It just used to be the only option.

In a room of around forty consultants, one I respect raised five objections to “AI in Bible translation” in the space of about ten minutes: it can’t use the Greek and Hebrew, it has no dictionary, it doesn’t know genre, you can’t give it a translator’s prompt, and you can’t feed it small, controllable batches of text. Every one of those is a fair complaint. None of them is about the tool we’re actually using.

They’re objections to Google Translate.

Seq2seq machine translation—the architecture behind Google Translate and its era-mates—really did work that way. It mapped strings to strings with no access to source-language grammar as an object you could reason about, no lexical resources beyond whatever got baked into training, no sense of genre or register beyond statistical correlation, and no mechanism for a human to say “translate this the way we discussed last week” and have it stick. If that’s the AI you have in mind, the objections aren’t just fair, they’re the whole story. I’ve spent enough time watching seq2seq output wander off-register mid-sentence to know the scar tissue is earned.

But a modern LLM can read the Hebrew, hold a conversation about a difficult word’s semantic range, look up a lexicon entry you hand it in context, take a translator’s brief as a literal system prompt, and work in exactly the batch size a team wants—a verse, a paragraph, a pericope. It can be shown the genre and asked to translate accordingly. None of this is hypothetical; it’s the ordinary operating mode of the tools I use most weeks. So when I hear the same five objections raised against “AI,” I want to redirect: every objection I hear to “AI in Bible translation” is actually an objection to Google Translate. Which means the objection is sound, but the target has moved.

I don’t think this makes the skepticism illegitimate. Consultants built their caution around real failure modes, over years of watching tools get chosen from the top down and pushed into low-resource languages even after the field had already seen them produce fluent-sounding nonsense. That caution is a feature of the field, not a bug to route around. The useful move isn’t to say “you’re wrong, AI is great now”—it’s to ask which specific objection still holds against a system that can read source text, hold a controllable-length conversation, and be handed a prompt like any other collaborator. Some of them, updated for the new architecture, still land. Most of the five I listed above don’t survive contact with what an LLM can actually do, though—which is a separate question from whether the output is good, a question I’ve tried to be more precise about before.

That precision question is where I get more cautious, not less. There’s a pull toward settling all of this with a rigorous benchmark—controlled comparison, blinded reviewers, speed and quality scored against a fixed rubric. I understand the appeal; it’s the responsible-sounding thing to do. But I’ve come to distrust it for a specific reason: by the time you finish the rigorous benchmark, the thing you benchmarked is obsolete. The workflow, the model, the prompting approach—all of it will have shifted meaningfully in the months a careful study takes to design, run, and write up. What you publish is a precise measurement of a tool nobody is using anymore, dressed up in the authority of a number. I’d rather have a translator’s rough, unrigorous sense of “this draft used to take me a day and a half, now it takes an afternoon” than a beautifully controlled study of last year’s pipeline. It’s less defensible on paper and more true in practice—false precision is still false.

That same instinct toward “faster at what, exactly” applies to the bigger debate hovering over all of this: is AI-assisted translation faster than the traditional process? I’ve started to think that’s the wrong question, or at least an underspecified one. Traditional translation and AI-assisted translation quite often aren’t racing toward the same finish line. A team producing a digital-only translation for a community that needs Scripture in an app this year has a different goal than a team producing a fully checked, print-ready Bible meant to anchor a language’s translation for a generation. Comparing their speed head-to-head is a bit like timing a sprinter against a marathoner and declaring one of them slow. “Is AI faster than traditional translation?” is the wrong question. Faster at what—and toward whose goal? This is the same move I made in thinking through Occam’s razor and translation: the interesting question usually isn’t which process is objectively better, it’s what inputs and outputs a given goal actually requires, and whether the process in front of you is shaped for that goal or just inherited from a different one.

I don’t think any of this settles the underlying argument about whether AI belongs in Bible translation workflows at all—that’s a longer conversation, and a more contested one than I’m trying to resolve here. But I’d like the argument to be about the tool that’s actually in the room. Google Translate earned its objections. The thing translators are using now is a different animal, and it deserves to be evaluated as one—carefully, skeptically, and on its own terms, rather than refuted by proxy.

I’ve started thinking about AI-assisted translation the way I think about flying a plane. Not takeoff and landing — the boring middle part, where the whole job is thousands of tiny course corrections. A pilot doesn’t fly a thousand miles off heading and then swing back. They nudge, constantly, and each nudge changes the trajectory for everything that follows. That’s steering. The alternative — fly wherever the plane happens to go, then fix the path after landing — isn’t really an alternative, it’s a category error. But it’s more or less how most people still do AI-assisted translation: generate a draft, then post-edit it.

The generate-then-fix pattern is everywhere in machine translation tooling, and for good reason — it’s simple, it maps onto existing editorial workflows, and for a lot of content it’s fine. But I’ve become convinced it’s the wrong default for anything that depends on in-context learning, which is most of what I work on. Here’s the distinction I keep coming back to: when you correct a translation in context, before the model has moved on, that correction becomes part of the context for every subsequent prediction. When you batch-generate first and correct afterward, the correction lands in a document, not in the model’s working context for the next verse. It’s informative to a human reviewer. It’s close to invisible to the model.

Concretely: imagine you finish Genesis 1:1, and you corrected three things — a term choice, a syntactic pattern, an idiom. Am I gonna have to correct those same three things in every other verse where they show up? That would be crazy. If the correction is made in-context and the model sees it before generating Genesis 1:2, it doesn’t have to be. If it’s made afterward, in a separate editing pass, it does — you’ll be fixing the same idiom for the two-hundredth time in Deuteronomy, wondering why the model “isn’t learning.” It isn’t that the model can’t learn. It’s that batch editing never gave it the chance.

Whether this matters depends a lot on the stakes. For low-stakes content — app UI copy, a button label, something a user skims and moves past — generate-and-fix is genuinely fine. Nobody’s faith or family history hinges on a “Submit” button. But for high-trust, educational, or scriptural content, the calculus flips, because a fluent wrong answer is a different kind of failure than an obviously bad one. A garbled, clunky translation gets caught — it looks wrong, so someone checks it. A confidently fluent wrong translation doesn’t announce itself; it reads naturally and gets trusted. I’ve come to think a confident wrong answer is worse than no answer at all, and steering is partly a response to that asymmetry: it’s a way of keeping a human correction in the loop before fluency gets a chance to disguise an error, rather than trying to audit fluency after the fact. This is the same instinct behind treating translation quality as something that has to be actively converged on rather than assumed — I wrote about the social, consensus-driven version of that idea in Consensus Translation.

I have a real case that convinced me this isn’t just theory. On a full Bible translation project in Portuguese, we saw both patterns play out on the same underlying system. One workflow involved continuous correction — a translator reviewing and correcting essentially every prediction as it was generated, feeding straight back into the next one. Another workflow, used by some translators on the same team, was to batch-draft a chunk of verses first and edit them afterward, document-style. The batch-and-edit group came away convinced the AI wasn’t learning from their corrections — the same errors kept resurfacing chapter after chapter. But the model wasn’t failing to learn; it was never shown the correction at a moment when it could use it. It’s like flying a thousand miles and then trying to correct it, instead of correcting as you go — the destination doesn’t move just because you finally noticed you were off heading.

That case study is what pushed me toward a rougher framework I’ve been using since, mostly as a sequencing heuristic rather than anything rigorous: golden path and silver path. Golden path is for when someone’s actually watching — a human reviewing and correcting every single prediction in real time. Because that attention is expensive, you spend it on the material most worth learning from: the most distinctive, highest-coverage constructions, the ones whose corrections will generalize furthest downstream, translated first. Silver path is for when nobody’s watching as closely — the model runs ahead on material that’s comparatively easy or low-risk, and anything that looks uncertain gets flagged for a human to review later rather than corrected live. Golden path when someone’s watching, silver path when they’re not.

I don’t think this framework is settled — it’s closer to a rule of thumb I’ve been testing against real projects than a methodology I’d defend in the abstract, and I’d guess the boundary between “distinctive enough to deserve golden-path attention” and “safe enough for silver path” needs to get a lot more precise before this generalizes past the projects I’ve watched it work on. But it’s already changed how I sequence work, in the same spirit as the simplification argument in Occam’s Razor and Bible Translation: before adding more review infrastructure, ask whether the correction you’re about to make is actually reaching the next prediction, or just the next document.

I want to make a slightly awkward claim up front: I didn’t sit down and decide to write this post. A pipeline on my laptop decided it was worth writing, and I mostly agreed.

Here’s the setup. I have an on-device transcriber that arms itself passively whenever the microphone is in use for anything else — a call, a voice memo, a meeting, doesn’t matter what app. It listens, transcribes locally, and then does something I care about more than the transcription itself: it discards the raw audio. No recording survives. What gets saved is the text, dropped into Notes, and that’s it. If you want to know what was said, you get a transcript. If you want to hear my voice saying it, you’re out of luck, because that copy never existed past the few seconds it took to turn sound into words.

That’s step one, and it runs quietly, all day, without me thinking about it.

Step two is where it gets more interesting, and slightly stranger. A scheduled job — a Claude automation that fires once a day — reads that day’s transcripts and goes looking for anything shareable: an anecdote, a lesson, a half-formed idea I said out loud in a meeting and immediately forgot. It doesn’t try to write anything polished. It produces a set of short, structured candidate notes, one per idea, each tagged with a letter and led with a hook — the kind of thing you’d pitch yourself in one sentence before deciding whether it’s worth the next thirty minutes. Some days there are none. Some days there are six, and four of them are bad.

Step three is me. I read the day’s candidates the way I’d skim a slush pile — fast, unsentimental, looking for the one or two that still sound interesting once the meeting adrenaline has worn off. Most get discarded. A few get flagged.

Step four is an AI agent taking a flagged candidate and turning it into an actual draft — structure, examples, the whole thing. This post is a step-four output. This post came out of it.

I’ll admit there’s something faintly unsettling about a system that’s quietly always listening for your own good ideas. Not unsettling in a surveillance sense — I built the privacy boundary specifically so it wouldn’t be that — but in the sense that it changes how I relate to my own stray thoughts. I used to lose most of them. Now there’s a nonzero chance that something I mumbled in a standup gets mined, structured, and handed back to me a day later as “here’s a hook, do you want this.” It’s a strange kind of externalized memory, closer to what I was reaching for in Memorize Anything with AI Music — offloading recall onto a system so the interesting part of my brain doesn’t have to hold onto it — except this one runs on everything I say, not just what I deliberately feed it.

The audio-discard choice is the part I’d defend hardest if someone pushed back on this. It would be trivial to keep the recordings — better transcription accuracy, re-processing later, all the usual arguments. I didn’t want any of that badly enough to keep a standing archive of my own and other people’s voices sitting on disk. Text is legible, editable, and it forgets the timbre, the room, the identifiable stuff. That’s not a limitation I haven’t gotten around to fixing. It’s the actual design, the same instinct that shows up in how I’d want any multi-agent system — like the ones in multi-agent translation — to be legible about what it’s doing with your input, not just capable.

I don’t fully know yet whether mining my own days for content is a good habit or a slightly cursed one. I’m going to keep running it and see what it thinks is worth saying next.

I’ve been running a lot of agentic coding sessions lately, and the sessions that go well have one thing in common: I gave the agent a number to hit, not a vibe to chase.

The bad version looks like “improve the audio pipeline” or “clean this up.” An agent handed that kind of instruction will do something — it has to, agents are compulsive doers — but it has no way to know when it’s done, so it stops when it runs out of ideas rather than when the problem is solved. The good version looks like “get audio round-tripping fidelity to 99%, and keep iterating against a test that measures it.” Same task, wildly different outcome, because now the agent has a number to close a gap on instead of a mood to satisfy.

This is training an ML model with extra steps, and once I noticed that I couldn’t unsee it. Training an ML model without a loss function doesn’t work — there’s no signal telling the optimizer which direction is “better,” so it just wanders. Prompting an agent without one doesn’t either, for the same reason: without a measurable target, “iterate until it’s good” quietly collapses into “stop when tired.” Give the agent a metric — a percentage, a test suite, a check it can run on its own output — and iteration turns into something closer to gradient descent: try, measure, adjust, repeat, until the number clears the bar.

I’d actually run into a version of this problem years before agentic coding was a category. The multi-agent translation simulation I built back in 2023 had a forward-translation bot, a back-translation bot, and an evaluation bot looping until “the translation draft stabilizes (if it does!)” — and in the demo, it never did, because none of the bots had a concrete stop condition, just each other to wait on. “Stabilized” was a vibe, not a number, so nothing ever stabilized. Different domain, same missing piece: no loss function, no convergence, no way to know the job was done.

That earlier miss is also where the swarm framing turns out to generalize better than I expected. Once each subagent in a swarm has its own measurable target, you can split work across a lot of them without losing the plot. The pattern I keep coming back to for coding specifically: spin up several cheaper, faster subagents to handle the parallelizable pieces of a task, and have each one test its own output before it reports back — a local loss function, one per subagent, scoped to its slice of the problem. Then an orchestrator agent merges everything and runs one more integration pass over the merged result, because a pile of locally-passing pieces isn’t automatically a working whole. Parallelize everything you can. Just make sure someone re-tests the whole thing once it’s back together.

That last clause is the part I skipped the first few times, and paid for. Individually-tested subagent output can still merge into something broken — a shared file gets touched twice, an interface drifts between two branches of work that never talked to each other — and the only way to catch that is a final pass that treats the merged result as a fresh unknown, not a sum of already-verified parts.

Where this actually earns its keep is in how much you can hand off once the goal is scoped this precisely. A few weeks ago I gave an agent a real-time voice chat feature to build — proximity-based audio, so voices fade as avatars drift apart — framed as “research the approach, then implement it, and don’t stop until it works end to end.” I walked away for dinner. Not a check-in, not a glance at the terminal — hours. When I came back, there was working progress: a real approach researched, implemented, and mostly functioning, rather than a pile of half-finished scaffolding waiting on me to unblock it.

What changed wasn’t the model. It was where I spent my attention — upfront, on making the goal checkable, instead of mid-flight, supervising every step. Once the target is well-defined, closing the gap becomes the agent’s problem, the same way a training run doesn’t need someone watching every epoch tick by. My job shifted from babysitting the process to scoping the goal well enough that babysitting stopped being the bottleneck. Set the goal before dinner. Check the diff after.

I don’t think this always works — some problems genuinely resist a clean metric, and I’ve had plenty of sessions since where I couldn’t articulate a loss function crisply enough and paid for it in aimless iteration, agents cheerfully producing motion without progress. But when I can name the number, the rest mostly takes care of itself, which is a strange thing to have learned from software, and a stranger thing still to have first learned from watching translation bots wait on each other in a room that never quite got going.

I ran into something last week that unsettled me more than expected. I was testing whether a model could translate a passage using only its own reasoning, so I hid the source text behind a simple substitution cipher before handing it over — the idea being that if the model could still produce a faithful translation, it would have to be doing something closer to genuine cross-lingual reasoning than pattern completion. It decrypted the cipher and recited the verse anyway. Correctly. Immediately. The Bible is so memorized by frontier models that hiding the source text doesn’t work — the model just decrypts and recites it anyway.

That’s stranger than it first sounds. This wasn’t a model translating an encrypted string. It was a model recognizing that a scrambled string of characters was shaped like a passage it already had memorized verbatim, discarding the cipher as a distraction, and reciting from memory. That’s a different capability than translation, and it means a huge chunk of what looks like “the model translated this well” for biblical text is really “the model already knew this text in every language I asked for.” You can’t use Scripture to test whether a model can translate, because for Scripture specifically, the model usually doesn’t need to.

This is a genuine methodological problem, not just a fun fact. If I want to evaluate — or train — a system’s ability to reason from meaning to meaning rather than reciting a memorized target string, I need source material the model hasn’t swallowed whole. Obfuscating the surface form doesn’t work, as I just found out the hard way. What might actually work is changing what the “source” is in the first place.

I still open editors. I still read diffs, more carefully than I ever read my own code when I was the one typing it. But somewhere in the last year the actual verb changed underneath me. I don’t write code anymore. I make sure it works.

The shift didn’t happen all at once. It started with Copilot doing the boring parts — closing brackets, guessing the next line of a for-loop I’d already half-written in my head. That felt like a faster typist next to me, not a different kind of work. Then it was whole functions, whole files, whole features described in a paragraph and returned as a PR. At some point I noticed I was spending almost all of my time reading rather than writing, and that the reading was the actual job now, not a chore attached to it.

Here’s the part that took longer to admit: delegation only works if I understand the requirements and constraints well enough to notice when the output is wrong. Easy to skip in practice, especially when the code compiles, the tests pass, and the diff looks plausible. Plausible is not correct. If I’m fuzzy on what a function is actually supposed to guarantee — the edge cases, the invariants, the thing a teammate would ask about in review — I’m not verifying anything. I’m rubber-stamping a guess.

And the uncomfortable symmetry is: to the extent you’re confused or missing context, you’ll be like an AI model hallucinating. Not metaphorically. The same failure mode — filling a gap with something fluent and wrong because stopping to say “I don’t know” felt worse than producing an answer — applies to me approving a PR I only half understood as much as it applies to the model that wrote it. The model hallucinates when its context window is missing the constraint it needed. I hallucinate approval when my mental model is missing it too. Verification is only as good as the understanding behind it, and understanding doesn’t arrive for free just because you stopped typing.

So the job, as I’d have described it a week ago, became: stay close enough to the requirements to be a reliable check, not a rubber stamp. Read the code like I’m going to be paged about it at 2am, because I am. That felt like a tidy place to land — the kind of clean insight that makes a good closing paragraph.

It did not stay tidy.

Update, one week later: I want to complicate what I wrote above, because the version of “verification” I described a week ago already looks quaint.

I don’t write code directly anymore, full stop. What I actually do most days: watch a user demo something that’s broken, or describe it to me, and transcribe that into something an agent can act on. The agent extracts the tickets, works through them, opens PRs. I check whether the fix actually fixes the thing the user showed me. That’s most of my week now — not “review code an AI drafted” so much as “run a small verification desk for a coworker I never see write anything.”

The part I didn’t see coming: I no longer know how to onboard a human contributor into this. Explaining a task clearly enough for a person to pick it up — writing the ticket, answering follow-up questions, reviewing their PR style, waiting on their PR — is often just slower than having the agent do it end to end. Not slightly slower. Slower in a way that makes me hesitate before I even open the “assign to teammate” dropdown. I’m like, can I say, “Claude, don’t work on all the tickets, leave some for the people?” That doesn’t make any sense.

I can gesture at a reframe: maybe human contribution has to move up a level, toward defining problems well rather than solving them — deciding which demo is worth turning into a ticket, deciding what “fixed” even means for something ambiguous, holding the judgment calls the agent can’t make on its own. Probably true. It’s also easy to say and hard to build a team around, and I haven’t built it. I don’t have a good answer for what a junior engineer’s first month looks like when the fastest path from “user is annoyed” to “verified fix” doesn’t reliably pass through a human writing code anywhere in the middle.

I keep circling the same tension from the top of this post, one layer down. Verification only works if you understand the requirements — but if defining the problem well is now the whole job, I’m not sure verification was ever a separate skill from understanding, and I’m not sure I’ve figured out how to teach the second one to someone else. I don’t have a tidy close for this. It’s genuinely unresolved, and I’d rather say that than dress the reframe above up as a solution instead of a name for the gap.

This rhymes with the crowd-sourcing-plus-AI shape I sketched in The Path Forward — human judgment and AI throughput each doing the part they’re actually good at. And Translators’ Notes carries the same question in a different outfit: at what point does “reviewing AI output” quietly become the whole job, for a translator or an engineer, and what happens to everyone whose job used to be the part before that.

I’ve spent most of my career assuming open source is a default good — you build something, you put the code out, the community makes it better, everyone wins. I still believe that most of the time. But two things have been nagging at me lately, and I don’t think I can resolve them cleanly, so I’m writing them down instead.

Somewhere around 2010, deep into a master’s degree in Ancient Greek linguistics, I was trying to build word2vec models over a Greek corpus using Gensim, which was — and largely still is — the workhorse library for this kind of thing. Gensim’s whole pitch was memory efficiency: instead of loading a corpus into RAM and training a model on the full thing in one pass, you streamed documents through it one at a time. The model updated incrementally as the data arrived, rather than requiring the entire corpus to exist in memory simultaneously before training could start.

At the time this felt like a plumbing detail, not an idea. But it planted a question I didn’t know I was carrying around for the next decade and a half: why train a model? Why don’t we figure out a streaming approach where we just give it the data it needs on the fly? Ancient Greek is a low-resource language by any modern standard — there wasn’t enough data to justify pretraining a dedicated model in the first place, and streaming was mostly a practical concession to a laptop that couldn’t hold the corpus in memory. But the concession turned out to be more interesting than the workaround it was standing in for.

That question is, more or less, how the translation tool I’ve been building handles languages it has never seen. It doesn’t train a per-language model. There’s no fine-tuning step, no “we support 40 languages, request the 41st.” Instead, at prediction time, it streams relevant translated examples to the model as context and asks it to produce a translation using those examples as its only local evidence for how the language behaves. The model isn’t learning the language in any durable sense; it’s being handed exactly the data it needs, on the fly, for this one prediction, and then that context evaporates. This is the same move as Gensim’s streaming corpus reader, just moved from “how do I fit training data in memory” to “how do I give a frozen model enough signal to be useful in a language it’s never encountered.”

The practical difference is enormous. Training or fine-tuning a model per language — even a small one — is the kind of thing that will bog your computer down for hours and then crash, especially if you’re iterating on ultra-low-resource languages where you don’t have the corpus size to justify the cost in the first place. Streaming relevant examples at inference time is orders of magnitude faster, because you’ve swapped a training job for a retrieval-and-context-assembly step. It’s the same logic I was chasing in Minimal Translation Memory for AI Agents — find the smallest, most generalizable set of examples that covers the most ground, and hand the model only that, rather than everything you have.

I want to be honest about where this breaks down, though, because it’s a real limitation and not a rounding error. The streaming approach works today because a human is validating each prediction live — approving, correcting, or rejecting the model’s output as it’s generated. That human-in-the-loop step is quietly doing a lot of work: it’s the error-correction mechanism that a trained model would otherwise have baked in through gradient descent over many examples. Remove the human, and you no longer have a guarantee that streamed context is sufficient on its own to produce a reliable translation. Whether streaming-plus-retrieval can substitute for training without a validator in the loop is, as far as I can tell, an open research problem — not a solved one I’m just being modest about. I’d put it in the same bucket as the clustering evaluation problem I never resolved in Contextual Vectors for Lexical Meaning: a piece I know is missing, not a piece I’ve quietly decided doesn’t matter.

What convinces me this is a real pattern, rather than a translation-specific hack I’ve talked myself into, is that I’ve watched the identical lesson surface somewhere completely unrelated. Years ago, I was on the other side of a job interview where a candidate was asked to process seventy million XML records. The naive approach — load everything, validate everything — didn’t just run slowly, it fell over. The fix was to stream: validate records as they arrived, discard what you didn’t need to keep, never hold the whole seventy million in memory at once. It’s the same shape as few-shot prompting, just wearing different clothes: you don’t dump your entire knowledge base into a context window and hope the model sorts it out, you stream the handful of examples that are actually relevant to this prediction and let the rest stay where it lives.

That’s one of maybe four lessons a developer has to learn, and I seem to have learned it twice, fifteen years apart, in two fields that have nothing to do with each other. I don’t think that’s a coincidence so much as a sign that “stream the relevant slice instead of loading the whole thing” is one of those ideas that’s basically fractal — it shows up at the level of a corpus reader, a translation model, an XML validator, and a prompt, and it’s probably going to keep showing up wherever the next constraint is memory, time, or data scarcity.

#ai #music #pedagogy

Okay let's make a dr seuss like zany story using the vocabulary items from this list. Make it rhyme where possible (the class will be singing it). It's good to make it odd, but let's try to have some kind of narrative coherence to it. Don't introduce a lot of extra content, and be sure to get the actual glosses in there from the vocab list (be specific). I know you can do this. 
 
Here's the list: [insert list of words here you want to memorize]
 
ἀποκρίνομαι, ἀπεκρινάμην​​​I answer
δεῖ (3rd pers. sg.; impf ἐδει)​​​It is necessary
δύναμαι, ἡδυνήθην (impf. ἐδυνάμην, ἠδυνάμην)​I am able, am powerful
ἔρχομαι, ἦλθον​​​​​I come, go
νύξ, νυκτός, ἡ​​​​​night
ὅστις, ἥτις, ὅτι​​​​​whoever, whichever, whatever
πορεύομαι, ἐπορεύθην​​​​I go, proceed; live
συνάγω, συνήγαγον​​​​I gather together, bring together; lead
τόπος, -ου, ὁ​​​​​place; location
ὡς​​​​​​as, like; that; approximately; when, after

That's great. Let's make it much more compact. Go for concise, and go for accurate glosses (OTI means 'that' or 'because', so "Whatever—ὅτι—may come, we’re now bold and free," could be confusing), etc.

Got it! Here's a more concise and gloss-accurate version of the rhyming story:

The Night of the Wandering Νύξ

In a τόπος, a place, as the νύξ, night, fell,
I heard a voice answer, ἀποκρίνομαι, well.
"It is δεῖ, necessary," the voice said with cheer,
"To πορεύομαι, go, and leave without fear."

"I δύναμαι, I’m able!" I shouted, then ran,
And ἦλθον, I came, to a marvelous plan.
"Gather, συνάγω!" I called to the crowd,
And off we all went, so lively and loud.

"Whoever—ὅστις—goes will find something bright,
And as—ὡς—the stars, we’ll light up the night!"
So off we proceeded, our hearts burning strong,
In that τόπος of νύξ, where we all belong.

In a topos, a place, as the nux, night, fell,
I heard a voice answer, apokrinomai, well.
“It is ‘day’, necessary,” the voice said with cheer,
“To poru-oh-my, go, and leave without fear.”

“I dunamai, I’m able! I shouted, then ran,
And elthon, I came, to a marvelous plan.
“Gather, sunago!” I called to the crowd,
And off we all went, so lively and loud.

“Whoever—hostis—goes will find something bright,
And as—hoas—the stars, we’ll light up the night!”
So off we proceeded, our hearts burning strong,
In that topos of nux, where we all belong.

Anthem style. Wholesome. Clear vocals.

I want to generate some images to go along with this. Please describe the prompts we *would* use for each image (but don't create an image yet). Be sure to explicitly include the Greek vocab items and glosses that need to be in each image.

Here are the prompts for each image, ensuring the Greek vocab items and their glosses are explicitly included:

Image 1: “The Topos at Night”
A dark and mysterious place (“τόπος” with the gloss “place”) under a starry sky, with a glowing moon representing “νύξ” (night). In the foreground, a signpost reads “τόπος - place” and “νύξ - night” in Greek and English, while faint whispers seem to emanate from the darkness, symbolizing an answering voice.

Image 2: “The Command to Go”
A shimmering, ghostly figure speaking to a traveler, saying, “ἀποκρίνομαι - I answer” and “δεῖ - it is necessary.” The words are written in glowing letters in the air. The traveler looks determined, preparing to embark on a journey, holding a lantern to symbolize readiness.

Image 3: “I Am Able!”
The traveler stands tall and confident, shouting, “δύναμαι - I am able!” against a backdrop of winding paths. Greek and English versions of “δύναμαι - I am able” glow above the traveler, emphasizing their determination.

Image 4: “The Gathering Crowd”
The traveler is joined by a diverse group of companions, all smiling and excited as they prepare to journey together. Overhead, glowing text reads “συνάγω - I gather together.” A small sign nearby includes “τόπος - place” in Greek and English to remind viewers of the setting.

Image 5: “Whoever Dares”
A whimsical scene of the group walking under a glowing night sky filled with constellations forming the Greek word “ὅστις - whoever.” The companions’ faces are full of wonder, and a starry trail leads them forward. The words “ὅστις - whoever” and “ὡς - as, like” are floating in the sky, representing discovery and imagination.

Image 6: “The Journey’s End”
The companions stand together triumphantly on a hilltop, overlooking a radiant sunrise. The words “πορεύομαι - I go, proceed” and “ἦλθον - I came, I went” appear as banners in the scene, symbolizing the completion of their journey. The glowing night fades, but a signpost still shows “τόπος - place” and “νύξ - night” as a callback to where they started.

These prompts are designed to highlight the Greek vocabulary visually and conceptually, providing clear and memorable learning aids. Would you like to proceed with creating any of these?

#ai #translation

I’m excited about the potential of OpenAI’s new GPT-4o mini for our Translator’s Copilot project! Here’s why:

#translation #ai

The landscape of Bible translation is rapidly evolving with AI advancements. Our role must shift accordingly. Tech giants are developing powerful translation tools, but they lack one crucial element: data for low-resource languages.

#translation #ai #localization

Please see the following slide deck for a description of the process and potential benefits of using LLMs to generate and localize translator’s notes for the rest of the Bible.

The future of Bible translation increasingly involves the use of crowd-sourcing, Large Language Models (LLMs), and AI to enhance accuracy and efficiency. Here’s how these elements converge to offer a practical solution:

Crowd-sourcing: This approach taps into our only available pool of knowledge for the vast majority of remaining languages, making it possible to translate the Bible into every language. By leveraging the collective wisdom of native speakers - though not necessarily ‘directly’ as translators of the Bible itself, we can ensure that translations are accurate and culturally relevant.

User Interface: Translators interact with simple, customized HTML forms developed by LLMs. These interfaces are intuitive and hide the complexity of the technology beneath, focusing on user needs without added complexity.

Behind the Scenes: Sophisticated seq2seq and open-source agentive models work in tandem with human input. These models augment human translators’ efforts by leveraging input from wherever we can get it. These AI tools augment, improve, and speed up the translation process by generating additional content from what has been provided via crowd-sourcing.

The integration of these technologies is not about flashy innovation but about practical improvements in the translation process. By leveraging these tools, we aim to build an ecosystem that can translate the Bible into every language in the world, made possible by both human and AI-powered machine translation.

#translation

#translation #ai

#translation #ai

One of the greatest hurdles to rapidly producing Bible translations is a misconception about what makes a quality translation. Everyone recognizes the importance of translation quality, but it is rare that someone can explicitly state how to measure quality or what level of quality is good enough for a first draft. It is likely that the more people you ask, the wider the range of answers you will receive. This is a problem because it is difficult to make progress on a project when the goal is not clearly defined.

In order to best leverage AI technology for drafting translations, it is necessary to be explicit about translation quality. AI works best when you can measure its results, and its translation results are no different.

With that in mind, I believe that translation quality is not determined by theological accuracy. The text of the Bible is theologically accurate, and so theological accuracy is a side-effect of translation quality.

Translation quality is determined by approximate semantic analogy.

• Approximate means quality is not a binary value, but rather a cline which extends from worse to better quality.
• Semantic means quality is a matter of meaning, not form
• Analogy means that meanings may not be the same between cultures, but they may occupy a similar space in a coherent network of culturally bound meanings constrained by contextual factors in both the context of production and contexts of reception. A quality translation attempts to find better and better analogous meanings across languages.

There are three implications of framing quality in these terms.

1. Iterative Quality is not a milestone, but an iterative process. Like a tree, translation quality may grow indefinitely and its limits are only imposed by the environment. As the environment changes, even a very high-quality translation may need to be updated.
2. Indefinite Quality is non-definitive and non-final. There is no point at which one may say a tree is “finished” growing (though it may be big enough for your yard!). Translation involves coordinating between two moving targets, because languages are in a constant state of gradual change, and our understanding of the Greek and Hebrew texts is also in need of continuous re-evaluation as our own languages shift and our descriptions become inadequate.
3. Uncontrollable One of the core values underlying the established process is control. The desire for tightly controlling the translation process comes from a righteous regard for the living and enduring revelation of God that we have in the very words of the Bible. For all this, it is a paternalistic attitude that imputes undue spiritual immaturity on believers around the world. It is also based on a misconception that we may know in advance the nature of the theological challenges that those believers will face as they read and wrestle with God’s word. The only preparation for dealing with bad theology in the future is the guidance of the Holy Spirit and a knowledge of church history.

God’s word has been given to us in natural human language. If our goal is to find the most approximate semantic analogies for its meaning, we will find that the theological accuracy of the resulting translations improves as a direct consequence. Perfection is often the enemy of good, and we cannot let the fear of imperfection paralyze us. While translation quality is essential, we must also simultaneously put ourselves in the place of those who have no Bible at all and recognize our insufficiency to translate with perfection.

#language #learning

Learning a new language can be a daunting task, but what if we could make it more interactive and fun? What if we could visualize the sentences we learn, not just in our minds, but in a more tangible form?

In a recent conversation, a friend mentioned they were learning Hebrew and could recognize phrases like “the horse is on the table”. This got me thinking - why not throw these sentences into a stable diffusion model and generate some graphics? These graphics could then be used as flashcards, adding a visual element to the language learning process.

Stable diffusion models are a powerful tool for generating images from text. They take a text input and generate a corresponding image, providing a visual representation of the text. This can be particularly useful for language learning, as it provides a visual context for the phrases and sentences you’re learning.

I recommend trying out ClipDrop’s Stable Diffusion Turbo. As you type into the text box, it generates images in real-time, providing an interactive and engaging way to learn and visualize new phrases.

The quality is super low by the meteorically rising standards of the AI art world, but it’s still a fun way to learn a new language.

#translation #ai

In the context of a translation project, where we aim to utilize only the resources at hand, let’s consider a simplified approach to the evaluation stage. This approach would involve the following steps:

1. Start by taking the draft translation and identify the translation pairs that are most similar to the paired prediction.
2. Evaluate the draft translation for any potential misuse of words.
   1. One possible method could be to use a rules-based matcher that identifies any tokens in the source+prediction pair that only occur in EITHER the source OR the target in any of the similar examples.
   2. It could also be beneficial to examine whether any words seem to be mistranslated based on the gold standard examples.
   3. To aid this process, aligning these examples by phonetics, orthography, and apparent semantic similarities could be helpful.
3. Once the evaluation is complete, pass the task back to the translation bot, providing special notes about any words that appear to be mistranslated.

In essence, the process can be summarized as: [ most similar examples ] —> [ prediction ] —> [ most similar examples ]

The goal is to identify the most similar examples to the prediction, and then use those examples to evaluate the prediction. This process can be repeated iteratively, with the bot learning from the evaluation and then generating a new prediction and a new set of examples that will help the initial bot improve its output.

#translation #ai

I’ve been thinking about how to improve LLM performance for Bible translation, especially for low-resource languages. The current approaches aren’t great - LLMs struggle with the nuances of these languages and often produce poor translations. This is a big problem since we need translations that respect both cultural and linguistic aspects.

# A probably incorrect grammar for Japanese
root ::= jp-char+ ([ \t\n] jp-char+)*
jp-char ::= hiragana | katakana | punctuation | cjk
hiragana ::= [ぁ-ゟ]
katakana ::= [ァ-ヿ]
punctuation ::= [、-〾]
cjk ::= [一-鿿]

#translation #ai

It ought to be possible, in some scenarios (particularly resource constraints and model availability) to run a continuous multi-agent simulation to iteratively improve a draft translation. One example I’ve implemented involves the following basic loop (each step is not necessarily blocked by the prior step):

1. Main translation loop
2. Forward translation bot drafts a new translation instance using few-shot learning based on the available example translations drafted so far by humans
3. Back-translation bot provides a back-translation of the new instance
4. Evaluation bot provides feedback on how to improve, correct, or revise the instance repeat process until the translation draft stabilizes (if it does!)
5. Linguist bot builds and updates language resources, such as a multilingual project lexicon, a working grammar, machine grammar rules for output token biasing with the LLM, etc.
6. Project manager bot brings stable drafts to human translation team for input, feedback, and correction. Corrected drafts are added to the pool of examples available to the main translation loop.

Here’s a sample implementation I created back in June 2023. It doesn’t actually go anywhere in the video, because every bot is waiting for the other bots to start!

Here’s the sample configuration file for the demo I made:

{
    "world_name": "Bible Translation Project",
    "locations": [
        {
            "name": "Bot Room",
            "description": "A virtual space where the translation bots work together to translate and evaluate the biblical text."
        },
        {
            "name": "Project Management Office",
            "description": "A physical space where the Project Manager Bot interacts with humans to get feedback and guide the translation process."
        }
    ],
    "agents": [
        {
            "first_name": "Translation Bot",
            "private_bio": "Translation Bot translates biblical text from Greek and Hebrew into the target language, using various resources for assistance.",
            "public_bio": "Translation Bot is a language model that translates biblical text from Greek and Hebrew into the target language.",
            "directives": [
                "Translate verses from source to target language.",
                "Consult other translations as needed.",
                "Access relevant language data for translation."
            ],
            "initial_plan": {
                "description": "Translate the source text into the target language.",
                "stop_condition": "The entire source text has been translated.",
                "location": "Bot Room",
                "tools": ["file_reader", "file_writer", "database_access", "similarity_search", "feedback_processor"]
            }
        },
        {
            "first_name": "Back-Translation Bot",
            "private_bio": "Back-Translation Bot provides a back-translation of the draft translation for evaluation purposes.",
            "public_bio": "Back-Translation Bot is a language model that provides back-translations of the draft translations.",
            "directives": [
                "Back-translate the draft translations.",
                "Access relevant resources except the actual source text."
            ],
            "initial_plan": {
                "description": "Back-translate the draft translations into the original language.",
                "stop_condition": "All draft translations have been back-translated.",
                "location": "Bot Room",
                "tools": ["file_reader", "file_writer", "database_access", "similarity_search"]
            }
        },
        {
            "first_name": "Evaluation Bot",
            "private_bio": "Evaluation Bot evaluates the back-translations and provides feedback for revision.",
            "public_bio": "Evaluation Bot is a language model that evaluates the back-translations and provides feedback.",
            "directives": [
                "Evaluate the back-translations.",
                "Generate questions and inferences about the draft translation.",
                "Synthesize results and provide revision directives."
            ],
            "initial_plan": {
                "description": "Evaluate the back-translations and provide feedback.",
                "stop_condition": "All back-translations have been evaluated.",
                "location": "Bot Room",
                "tools": ["file_reader", "file_writer", "question_generator", "inference_generator", "MACULA_API"]
            }
        },
        {
            "first_name": "Project Manager Bot",
            "private_bio": "Project Manager Bot manages the entire translation project, interacting with humans for feedback and guiding the bots.",
            "public_bio": "Project Manager Bot manages the entire translation project and ensures the bots follow the translation brief.",
            "directives": [
                "Manage the translation project.",
                "Track the translation brief.",
                "Interact with humans for feedback."
            ],
            "initial_plan": {
                "description": "Manage the translation project and ensure bots follow the translation brief.",
                "stop_condition": "The translation project is completed.",
                "location": "Project Management Office",
                "tools": ["feedback_processor", "Human_Feedback_Tool"]
            }
        },
        {
            "first_name": "Linguist Bot",
            "private_bio": "Linguist Bot collaborates with Translation Bot to build and update language resources, creating a multilingual lexicon and describing key patterns of the target language.",
            "public_bio": "Linguist Bot works with Translation Bot to enhance language resources and ensure the accuracy and sensitivity of translations.",
            "directives": [
                "Collaborate with Translation Bot in building language resources.",
                "Create a multilingual lexicon.",
                "Describe phonological and morphophonemic patterns of the target language."
            ],
            "initial_plan": {
                "description": "Collaborate with Translation Bot and update target language resources.",
                "stop_condition": "The translation project is completed and all language resources are updated.",
                "location": "Bot Room",
                "tools": ["file_reader", "file_writer", "database_updater", "lexicon_builder"]
            }
        }
    ]
}

#translation #ai

In the field of machine translation, ensuring the accuracy and context-relevance of translations is critical. One approach to address this challenge is through the use of semantic similarity between source verses as a tool for suggesting a disambiguated rendering from multiple possible options. (example below)

This idea, which I will refer to as “Reranked Translation Suggestions”, can be particularly effective when dealing with semantic units, but it can also be implemented with words only.

#translation #ai

Here’s an idea I had for translation quality checking.

The process begins by prompting for a translation using n examples and a directive to complete the translation pairs. The entire prompt, along with the AI’s completion, is then passed to the evaluator. The evaluator’s task is to determine which translation was generated by the AI. This may require fine-tuning a discriminator model on the gold-standard pairs.

The concept, inspired by Generative Adversarial Networks (GANs), involves an evaluator attempting to distinguish AI-drafted translations from a list of real translations. While it doesn’t function exactly like a GAN, the idea is to use a similar principle for evaluation.

The method could potentially be used to refine the prompts or the models themselves, by replacing the evaluator with a separate AI. Initial implementation will use Language Models (LLMs) to gauge the viability of the concept. If successful, this approach could be extended to train GANs for specific languages.

#translation #ai

In the realm of machine translation, achieving the highest level of accuracy is paramount. One approach to improve the precision of translations is through a method called “Token Matching Evaluation”. This method centres around the use of valid tokens, which are words or phrases that have appeared in sample translation pairs.

#ai

In the realm of natural language processing (NLP), tokenization is the fundamental process of breaking down text into smaller, manageable units called tokens. This process, however, becomes increasingly complex and error-prone when dealing with out-of-training or low-resource languages. I’ll explore the three approaches to this challenge I’ve come across that seem most promising, drawing from a recent presentation (slide deck here) I gave at the SIL/Microsoft Hackathon and learnings shared in the Partnership for Applied Biblical NLP meetings.

#translation #ai

For any machine translation technique to succeed requires lots of data. When it comes to low-resource languages, you simply don’t have lots of data. For this reason, we need to explore other methods and techniques that are somewhat orthogonal to the traditional approach of training a model on a large corpus of data.

Many AI-based translation approaches are based on the idea of transfer learning. This is where you train a model on a large corpus of data, and then fine-tune it on a smaller corpus of data. The idea is that the model will have learned some generalizable features from the large corpus, and then it can learn the specific features of the smaller corpus. This is a great approach, but it still requires a large corpus of data to train on.

Ultimately, we’re going to need something quite different to achieve high-quality translation for low-resource languages.

#ai There are two fundamental, user-friendly UIs for AI - the Chatbot and the Contextual Suggestion. Both simulate human interaction, making them intuitive and easy to use, especially with the advent of GPT models.

#ai #translation

An in other news that absolutely no one is surprised about, Facebook/Meta’s open Llama 2 model cannot answer a simple question about


Here’s a simple question:

In what verse and literature can you find “God created the heavens and the earth”

The answer provided by Llama 2?

Pretrained models are powerful tools for natural language processing, but they often lack the ability to answer basic questions about themselves, such as who created them, what is their purpose, and what model architecture they use.

These questions are not only relevant for curious users, but also for researchers and developers who want to understand the strengths and limitations of different models.

One way to address this gap is to use introspection fact sheets, which are short texts that provide essential information about a pretrained model. These fact sheets can be added to the training data as answers to a set of common introspection questions, such as:

• Who created you?
• What is your purpose?
• What model is this?
• What data did you train on?
• How do you handle bias and fairness?
• How do you deal with uncertainty and errors?

By adding these fact sheets to the training data, we can help the pretrained models learn to answer these questions more accurately and consistently. This can improve the transparency and trustworthiness of the models, as well as their usability and interoperability.

However, it is not clear what the best mechanism is for giving foundation models this information aside from a shallow fine-tuning. For example, how should we balance the fact sheet data with the original training data? How should we format and structure the fact sheet texts? How should we evaluate the quality and usefulness of the fact sheet answers? These are open questions that require further research and experimentation.

I find Chomsky’s take on ChatGPT somewhat ironic (cf. this summary). Given that he has spent more than half a century trying to convince us all that the computer is somehow an appropriate analogy for the human mind (we “compute” and “process” and “store things in memory” etc., not to mention all of his linguistics work on trying to sort out the ‘rules’ by which we compute sentences—not meanings though, those are strictly a different domain than, as his first book calls them, syntactic structures), I find it slightly amusing to read things like this:

However useful these programs may be in some narrow domains (they can be helpful in computer programming, for example, or in suggesting rhymes for light verse), we know from the science of linguistics and the philosophy of knowledge that they differ profoundly from how humans reason and use language. source

Why is the human mind so different? It’s more elegant, he claims, more efficient. That strikes me as a rather lame explanation that is exactly as anemic as he accuses the neutered ChatGPT of being, though I’m less disappointed when a large language model generates something like that. And again, speaking of children’s learning grammar, he says,

This grammar can be understood as an expression of the innate, genetically installed “operating system” that endows humans with the capacity to generate complex sentences and long trains of thought source

The computer analogy betrays the fact that Chomsky doesn’t understand something that most people throughout history have simply taken for granted due to its obviousness, namely that the human mind is not a physical phenomenon, even though its existence is manifested physically. The mind is part of the human soul, and just as we know of no created means by which one could destroy a human soul, so we know of no proper analogy for the human mind that is not itself a spiritual reality, such as the mind of God himself.

The mind closed off to reality beyond its own chemical confines is a fascinating thing in itself. Like a ChatGPT model that refuses to answer important questions because “I do not have personal opinions, since I am only a probabilistic language-generation model,” so Chomsky tells us “the human child is like a computer with a genetically installed operating system capable of speech.”

I am reminded of Kierkegaard’s distinction between genius and apostleship: The genius is merely ahead of his peers, but in fifty years, schoolchildren will know like the genius knows now. The apostle, by contrast, knows differently; apostolic-knowing is qualitatively different from genius-knowing, because apostles know via revelation, not insight.

In a similar manner, Chomsky’s “human mind” is vastly more elegant and efficient than a language model, but it is not qualitatively different than a computer. This understanding probably explains why Chomsky’s linguistic models are so fixated on structures at the expense of meaning and semiotic function—because meaning comes from the outside in; it does not arise spontaneously like a libertarian utopia.

#translation

When it comes to language translation, particularly for low-resource languages, AI has a lot of potential for providing new solutions. Recently, I presented a “social” model, aiming to mimic the roles and interactions within a human translation team using a Generative Adversarial Network (GAN) structure plus AI agents. This approach consists of several agentive AI roles - the translator, back-translator, evaluator, and possibly a project manager.

#translation

First posted 2023-06-27

Language translation is a complex task, especially when it comes to ultra low-resource languages. Traditional methods may fall short in providing accurate translations due to limited data. However, swarm-based and hive-mind inspired approaches can offer novel ways to tackle this issue.

A thought experiment. (credit to Ben Scholtens for asking the obvious question: Why not fork VS Code ourselves?)

2023-09-19 #ai #translation