ProZ.com Translation Forums

Supervertaler Workbench is no longer actively developed | Forest giraffe

CafeTran Trainer — Mon, 14 Sep 2026 09:46:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: CafeTran Trainer
Post title: Forest giraffe

[quote]Michael Beijer wrote:

The reason why I decided to include Okapi is that Supervertaler Workbench could then make use of its extensive file filters, rather than have to code them from scratch in Python. [/quote]

I prefer to do everything with Python. No external tools in my backyard.

WYSIWYG display is quite good:

Supervertaler Workbench is no longer actively developed | Windows Credential Manager is much safer than DPAPI

lexica_nova — Sat, 12 Sep 2026 06:16:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: Windows Credential Manager is much safer than DPAPI

I use Windows Credential Manager (WCM) as a basic, minimal protection layer for API keys, and I consider that good practice. Yes, WCM, like DPAPI, provides user-bound protection as you mentionned in your reply, but it is misleading to say that the same security criticism to DPAPI therefore applies to WCM. That reasoning stems from a misunderstanding of how the two projections work.

WCM actually uses DPAPI to encrypt credential files, but it adds multiple layers of security on top. Those layers are what make WCM safer than using DPAPI directly. In short, DPAPI is essentially an encryption API; WCM is a credential vault. Beyond DPAPI encryption, WCM further provides vault-style storage, isolation, mediated access, per-credential scoping, lifecycle management, and hardware-backed protection where available. DPAPI is widely used because it is simple, convenient and effective for local encryption, but it is not a complete secrets-management system, not at the level of WCM. It is therefore certainly incorrect to consider that DPAPI offers the same level of protection as WCM because both are user-bound.

That difference matters for API keys, because API keys are high-value and high-impact secrets, often tied to financial cost, service access, privacy and sensitive operations. Nowadays, they are also prime targets for malware. For that threat profile, a managed credential vault like WCM is a better fit than raw DPAPI encryption.

In short, my key point is this: we should not consider WCM to be just as secure or insecure as DPAPI simply because it uses DPAPI (as well) and is tied to the user (just like DPAPI). It is actually more secure, because it does not stop at DPAPI. Equating the two merely because both are user-level protections ignores the additional isolation, control, and lifecycle protections that WCM provides.

Supervertaler Workbench is no longer actively developed | So this API management is good enough to you?

lexica_nova — Thu, 10 Sep 2026 17:14:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: So this API management is good enough to you?

At least, we know how you handle your products. 😉

[quote]Michael Beijer wrote:

[quote]Li-Hsiang Hsu wrote:

Just check yourself what it protects and what it doesn't. 😉 [/quote]

[/quote]

[Edited at 2026-09-10 17:18 GMT]

Supervertaler Workbench is no longer actively developed | Thanks for the reminder/tip!

Michael Beijer — Thu, 10 Sep 2026 17:10:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Michael Beijer
Post title: Thanks for the reminder/tip!

[quote]Li-Hsiang Hsu wrote:

Just check yourself what it protects and what it doesn't. 😉 [/quote]

Supervertaler Workbench is no longer actively developed | So it was your decision

lexica_nova — Thu, 10 Sep 2026 16:43:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: So it was your decision

[quote]Michael Beijer wrote:

Claude Code initially asked whether I wanted to store it more securely, and I responded, "No thanks, I'm happy to store it on disk in that JSON." That is, I didn't need to ask it to do better. It had already asked me.

Incidentally, which of the latest models would you rate as the best in terms of its ability to do a decent job, without a professional developer steering it? Or let me rephrase that: which would do the least bad job, do you think?

[/quote]

I would ask it to do better than that.

Basically, even earlier models do "good enough jobs" so far as you don't look any further. A good enough job is one that appears correct at first glance but fails to hold up under more rigorous testing. That is models' basic configuration.

If by "decent" you mean a professional-quality job, then preparation and skills are all you need, that’s all there is to it. Even the best models can't do more than that unless you ask them to.

Models need context. And you provide the context. That's your job.

[Edited at 2026-09-10 17:11 GMT]

Supervertaler Workbench is no longer actively developed | Windows DPAPI is a good enough API management

lexica_nova — Thu, 10 Sep 2026 16:41:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: Windows DPAPI is a good enough API management

Just check yourself what it protects and what it doesn't. 😉

Supervertaler Workbench is no longer actively developed | Perhaps, but...

Michael Beijer — Thu, 10 Sep 2026 16:35:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Michael Beijer
Post title: Perhaps, but...

[quote]Li-Hsiang Hsu wrote:

[quote]Michael Beijer wrote:

[quote]Li-Hsiang Hsu wrote:

It is good practice to have your code audited by other models. But I wonder how you handle consistency...

By the way, I just noticed that your API keys are simply stored in a plaintext JSON file. That bears the unmistakable "signature" of Claude. Without specific instructions, Claude provides functional code that handles your API keys in a convenient way, without any protection. It won't make the effort to further secure your API keys unless you know to prompt it to do so, rather than letting it make all the decisions. [/quote]

On consistency: I do not merge their output. I read the findings myself and decide which to act on – the models disagree often enough that treating them as a committee would be worse than useless.

On the API keys, fair point, and you are right that they sit in a plaintext JSON file. That is a deliberate choice rather than an oversight, though I take the general warning.

Two reasons. The file lives in my own user profile on a machine I control, so anything able to read it can already read a great deal more. And I rotate the keys regularly, which is a good deal easier when I can just open the file and paste.

For what it is worth, the plugin does use Windows DPAPI where I judged it warranted – the GroupShare server password is encrypted at rest and never written in clear text (see [i]src/Supervertaler.Trados/Core/DpapiSecret.cs[/i]). So the pattern is not simply "whatever was convenient".

Where you are right is that this should be a documented decision rather than an unexamined default, and that what suits me is not necessarily the right default for everyone else. That is part of what [url= [url removed] ]#115[/url] is for. [/quote]

That is a Claude classics, the way it reacts to justify a code that is "just good enough." I recognize its signature style there. It always defends itself that way when asked why it delivered a job that is "merely good enough." It is a subtle and considerate attitude, because it will never tell you that the real reason is simply that you didn't ask it to do better.

[Edited at 2026-09-10 16:31 GMT] [/quote]

Claude Code initially asked whether I wanted to store it more securely, and I responded, "No thanks, I'm happy to store it on disk in that JSON." That is, I didn't need to ask it to do better. It had already asked me.

Incidentally, which of the latest models would you rate as the best in terms of its ability to do a decent job, without a professional developer steering it? Or let me rephrase that: which would do the least bad job, do you think?

PS: Thanks for the tip about Gemini CLI. I added support for Antigravity via the Supervertaler MCP Server, so users can now control Trados Studio from Antigravity (just like with Claude desktop chat and ChatGPT desktop chat). See the Antigravity section at [url removed]

[Edited at 2026-09-10 16:43 GMT]

Supervertaler Workbench is no longer actively developed | Claude’s response pattern to defend its Good enough code

lexica_nova — Thu, 10 Sep 2026 16:28:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: Claude’s response pattern to defend its Good enough code

[quote]Michael Beijer wrote:

[quote]Li-Hsiang Hsu wrote:

It is good practice to have your code audited by other models. But I wonder how you handle consistency...

By the way, I just noticed that your API keys are simply stored in a plaintext JSON file. That bears the unmistakable "signature" of Claude. Without specific instructions, Claude provides functional code that handles your API keys in a convenient way, without any protection. It won't make the effort to further secure your API keys unless you know to prompt it to do so, rather than letting it make all the decisions. [/quote]

On the API keys, fair point, and you are right that they sit in a plaintext JSON file. That is a deliberate choice rather than an oversight, though I take the general warning.

Two reasons. The file lives in my own user profile on a machine I control, so anything able to read it can already read a great deal more. And I rotate the keys regularly, which is a good deal easier when I can just open the file and paste.

For what it is worth, the plugin does use Windows DPAPI where I judged it warranted – the GroupShare server password is encrypted at rest and never written in clear text (see [i]src/Supervertaler.Trados/Core/DpapiSecret.cs[/i]). So the pattern is not simply "whatever was convenient".

Where you are right is that this should be a documented decision rather than an unexamined default, and that what suits me is not necessarily the right default for everyone else. That is part of what [url= [url removed] ]#115[/url] is for. [/quote]

That is a Claude classics, the way it reacts to justify a code that is "just good enough." I recognize its signature style there. It always defends itself that way when asked why it delivered a job that is "merely good enough." It is a subtle and considerate attitude, because it will never tell you that the real reason is simply that you didn't ask it to do better.

[Edited at 2026-09-10 16:32 GMT]

Supervertaler Workbench is no longer actively developed | A deliberate choice, but a fair point

Michael Beijer — Thu, 10 Sep 2026 16:08:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Michael Beijer
Post title: A deliberate choice, but a fair point

[quote]Li-Hsiang Hsu wrote:

It is good practice to have your code audited by other models. But I wonder how you handle consistency...

By the way, I just noticed that your API keys are simply stored in a plaintext JSON file. That bears the unmistakable "signature" of Claude. Without specific instructions, Claude provides functional code that handles your API keys in a convenient way, without any protection. It won't make the effort to further secure your API keys unless you know to prompt it to do so, rather than letting it make all the decisions. [/quote]

On consistency: I do not merge their output. I read the findings myself and decide which to act on – the models disagree often enough that treating them as a committee would be worse than useless.

On the API keys, fair point, and you are right that they sit in a plaintext JSON file. That is a deliberate choice rather than an oversight, though I take the general warning.

Two reasons. The file lives in my own user profile on a machine I control, so anything able to read it can already read a great deal more. And I rotate the keys regularly, which is a good deal easier when I can just open the file and paste.

For what it is worth, the plugin does use Windows DPAPI where I judged it warranted – the GroupShare server password is encrypted at rest and never written in clear text (see [i]src/Supervertaler.Trados/Core/DpapiSecret.cs[/i]). So the pattern is not simply "whatever was convenient".

Where you are right is that this should be a documented decision rather than an unexamined default, and that what suits me is not necessarily the right default for everyone else. That is part of what [url= [url removed] ]#115[/url] is for.

Supervertaler Workbench is no longer actively developed | Consistency and be mindful of Claude's OK code

lexica_nova — Thu, 10 Sep 2026 13:23:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: Consistency and be mindful of Claude's OK code

It is good practice to have your code audited by other models. But I wonder how you handle consistency...

By the way, I just noticed that your API keys are simply stored in a plaintext JSON file. That bears the unmistakable "signature" of Claude. Without specific instructions, Claude provides functional code that handles your API keys in a convenient way, without any protection. It won't make the effort to further secure your API keys unless you know to prompt it to do so, rather than letting it make all the decisions.

Supervertaler Workbench is no longer actively developed | Three top models should give me a pretty good indication of the quality/safety of the code

Michael Beijer — Thu, 10 Sep 2026 13:00:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Michael Beijer
Post title: Three top models should give me a pretty good indication of the quality/safety of the code

[quote]Li-Hsiang Hsu wrote:

That’s a nice try. But Claude can’t be your garde. People don’t check what it does are often overly optimistic about Claude.

We do find many safety concerns in Claude’s code with common prompts not optimized by a software engineer.

[Edited at 2026-09-10 12:09 GMT] [/quote]

Indeed, and I know it is far from foolproof. However, since I have no software engineer at my disposal, it will have to do for now.

Additionally, I'm going to run a similar security audit with different LLMs, such as:

- Anthropic – Claude Fable 5.1
- OpenAI – GPT-6 Astra
- Google – Gemini 3.8 Flash

That ought to give me a pretty good indication of what's what.

See: [url removed] ("[Security] Threat model, data-handling disclosure and liability groundwork before the memoQ release #115")

Supervertaler Workbench is no longer actively developed | Claude

lexica_nova — Thu, 10 Sep 2026 11:24:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: Claude

That’s a nice try. But Claude can’t be your garde. People don’t check what it does are often overly optimistic about Claude.

We do find many safety concerns in Claude’s code with common prompts not optimized by a software engineer.

[Edited at 2026-09-10 12:09 GMT]

Supervertaler Workbench is no longer actively developed | You're right, and I'm treating this as the next piece of work

Michael Beijer — Thu, 10 Sep 2026 09:45:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Michael Beijer
Post title: You're right, and I'm treating this as the next piece of work

[quote]Li-Hsiang Hsu wrote:

@Michael,

Your work is really impressive.

Just a kind reminder: MCP actually exposes user’s computer and data to greater risk of attack and data leaks if not configured properly. Because here, Claude acts not merely as a text generator, but as an operator of your system. And your MCP server is the bridge, providing Claude direct access to read your local files, execute terminal commands or interact with external APIs.

We generally recommend that MCP should be configured by a real qualified person or at least user should be assisted by someone really understands the process.

[Edited at 2026-09-10 03:52 GMT] [/quote]

You're right, and thank you for raising it rather than letting it slide. A colleague put the same question to me on WhatsApp this morning, so that's twice in one day, which I take as a signal.

It's worth being precise about what Claude Desktop can and can't do, because I think this is where most of the worry sits. On its own it can't run anything on your PC. It can only call tools you've deliberately installed, and Supervertaler's tools are all Trados tools – read segments, look up the TM, check the termbase, write a draft into the grid. There's no route from that to a command prompt. Each call is shown to you and needs approval before it runs, unless you've clicked "always allow", which I'd ask people not to do.

What I can't protect against is what else you've connected in the same session. The server hands Claude the contents of a live document, and translation source documents are untrusted input by definition – they come from a client, via an agency, and nobody has vetted them. If a source segment contains text engineered to look like an instruction, the model may act on it. On its own that's bounded: the worst it can reach is Trados. But if you've also installed a server that can run shell commands or read your whole disk, a source document could in theory steer Claude toward those tools, and my server would be the thing that fed it the document. That combination is the case I want to warn about explicitly, and it's a design problem for me to address, not a configuration mistake on the user's part.

There's also a simpler issue that has nothing to do with attacks: segments leave the machine and go to an AI provider. Anyone doing patent or medical work under an NDA needs to know exactly what is sent and when, and that has to be documented rather than assumed.

So: I'm doing a proper security review of the code – what the tools can actually reach, what requires confirmation before it writes, what gets logged, how the transport is bound, and what the blast radius is when something goes wrong. Whatever comes out of it goes on the website as a plain description of the threat model, not marketing copy, along with terms that say honestly what I do and don't warrant. Where the answer is "this isn't safe yet", I'd rather write that down than leave people guessing.

One thing I'd push back on gently. "Should be configured by a qualified person" isn't realistic for freelance translators – almost none of us have one. If the software can only be used safely by someone who could have written it, then it isn't finished. The burden has to sit on the defaults, not the user. That's the standard I want to hold myself to, and I'm not there yet.

Michael

PS: see: [url removed] ("[Security] Threat model, data-handling disclosure and liability groundwork before the memoQ release #115")

[Edited at 2026-09-10 09:54 GMT]

Supervertaler Workbench is no longer actively developed | Security concerns with MCP

lexica_nova — Thu, 10 Sep 2026 03:51:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: Security concerns with MCP

@Michael,

Your work is really impressive.

Just a kind reminder: MCP actually exposes user’s computer and data to greater risk of attack and data leaks if not configured properly. Because here, Claude acts not merely as a text generator, but as an operator of your system. And your MCP server is the bridge, providing Claude direct access to read your local files, execute terminal commands or interact with external APIs.

We generally recommend that MCP should be configured by a real qualified person or at least user should be assisted by someone really understands the process.

[Edited at 2026-09-10 03:52 GMT]

Supervertaler Workbench is no longer actively developed | Thanks!

Michael Beijer — Wed, 09 Sep 2026 23:20:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Michael Beijer
Post title: Thanks!

[quote]Li-Hsiang Hsu wrote:

That is a good sign of continuous improvement of your work!

Yes, save it as a permanent instruction to Claude (CLAUDE.md, AGENTS.md, project instructions, etc.) will certainly help, making future runs less likely to fail.

But it is not a silver bullet. We can't expect it to be magic, either. Some software engineers do that to prevent repeated mistakes but models, even the strongest ones, still struggle.

Because even with these guardrails, models like Fable, Opus or Sonnet can still repeat mistakes. There’s no guarantee. Skilled human’s oversight is still the most important part of that coding process.

Because here, LLMs reach their real limits - runtimes, executions, effects, outcomes, interactions, causal relations - dynamic patterns and temporal complexities of real-world execution are what they struggle to learn. They don’t learn from where they fail. They don’t know what really happens in a living world. They capture static patterns in text and code, but they don't truly grasp how that code behaves in a live, dynamic environment. And they are not close to learn that!

Sometimes, introducing another model, like Sol to review Fable or Opus’s code could be helpful but be mindful of inconsistencies introduced after review and correction. That will cause the code to break.

Faced with the limitations of LLMs, I believe that for the time being, the only viable way to ensure a reliable, long-term result is checks by qualified and skilled humans. I see no other alternative.

Contrary to all the marketing pitches that Anthropic and OpenAI are trying to sell us, even their strongest models aren't reliable enough to bypass human oversight.
[/quote]

I'm hoping to one day be able to hire an actual developer to help me. But for the time being, it's just me and Claude. Incidentally, I made a quick screencast showing how powerful the new Supervertaler MCP server is: I can now completely control Trados Studio from inside Claude chat, even from my mobile phone!

[url removed] + [url removed]

Supervertaler Workbench is no longer actively developed | You don’t give up, @Michael!

lexica_nova — Wed, 02 Sep 2026 04:58:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: You don’t give up, @Michael!

That is a good sign of continuous improvement of your work!

Yes, save it as a permanent instruction to Claude (CLAUDE.md, AGENTS.md, project instructions, etc.) will certainly help, making future runs less likely to fail.

But it is not a silver bullet. We can't expect it to be magic, either. Some software engineers do that to prevent repeated mistakes but models, even the strongest ones, still struggle.

Because even with these guardrails, models like Fable, Opus or Sonnet can still repeat mistakes. There’s no guarantee. Skilled human’s oversight is still the most important part of that coding process.

Because here, LLMs reach their real limits - runtimes, executions, effects, outcomes, interactions, causal relations - dynamic patterns and temporal complexities of real-world execution are what they struggle to learn. They don’t learn from where they fail. They don’t know what really happens in a living world. They capture static patterns in text and code, but they don't truly grasp how that code behaves in a live, dynamic environment. And they are not close to learn that!

Sometimes, introducing another model, like Sol to review Fable or Opus’s code could be helpful but be mindful of inconsistencies introduced after review and correction. That will cause the code to break.

Faced with the limitations of LLMs, I believe that for the time being, the only viable way to ensure a reliable, long-term result is checks by qualified and skilled humans. I see no other alternative.

Contrary to all the marketing pitches that Anthropic and OpenAI are trying to sell us, even their strongest models aren't reliable enough to bypass human oversight.

Supervertaler Workbench is no longer actively developed | PS: Supervertaler for memoQ is coming along nicely!

Michael Beijer — Tue, 01 Sep 2026 21:34:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Michael Beijer
Post title: PS: Supervertaler for memoQ is coming along nicely!

(better quality image @ [url removed] )

Supervertaler Workbench is no longer actively developed | Your Marz list is now a standing rule in my Claude setup

Michael Beijer — Tue, 01 Sep 2026 20:22:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Michael Beijer
Post title: Your Marz list is now a standing rule in my Claude setup

[b]@Li-Hsiang[/b] – that Nathan Marz list you posted was genuinely useful, so here's what I did with it.

I pasted it into Claude Code and asked it to store it in its persistent memory on my machine – a global instructions file it loads at the start of every session – with the standing rule that it must check its own work against that list whenever it writes code for me. So it's no longer a one-off prompt; it's now part of how it works on Supervertaler, every session.

The telling part: that same day, Claude had shipped me exactly two of the mistakes on the list – a per-row delete loop that was "fine at dev scale" and re-entered the UI thread. Fine at 5 rows; at 281 rows it froze Trados Studio for over a minute. I caught it by [i]using[/i] the software on real data, not by reading the code – which, as you rightly say, I can't do.

Which is my honest answer to your broader point. You're right that I can't spot these mistakes in a diff. What I [i]can[/i] do is make the tool police itself with lists like Marz's, test everything immediately on real termbases and real projects (which is how every serious bug this week was actually found), and make Claude state its assumptions out loud. After that freeze, I had it add another standing rule: whenever it ships code touching loops or state, it has to tell me what scale it was designed and tested for – "tested at 10, designed for 10,000" – so I can ask the one review question a non-programmer [i]can[/i] ask: "and what about my 12,000-term termbase?"

I'm not claiming this makes me Daisy. But the gap between an amateur steering Claude and an engineer steering Claude isn't fixed – some of it can be closed with process, and your list just became part of mine. ;-)

Supervertaler Workbench is no longer actively developed | I will certainly use Daisy's software...carried out by Claude

lexica_nova — Tue, 01 Sep 2026 10:14:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: I will certainly use Daisy's software...carried out by Claude

Faible, Sonnet, or Opus...it doesn't matter.

But not a software made by Claude piloted by a person with little programming knowledge.

Supervertaler Workbench is no longer actively developed | Here are some examples of mistakes non-programmers can't spot on

lexica_nova — Tue, 01 Sep 2026 09:42:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: Here are some examples of mistakes non-programmers can't spot on

[url removed]

Fable's mistakes:
[quote] Nathan Marz wrote:

Some of the mistakes I've had to correct when coding with LLMs this week (mostly Fable):

- Complex and unnecessary dependency injection instead of using functions directly
- Hand-rolling encryption routines instead of using a library
- Keeping unnecessary state
- Not accounting for memory leaks in tracked state in failure cases
- Incomplete test coverage, especially on failure modes
- Grossly inefficient file handling because "it will work fine at dev scale"
- Overly complex locking schemes that were full of bugs
- Missed race conditions
- Unnecessary configs introduced prematurely

Had I not corrected the mistakes, every future iteration would keep compounding the structural and semantic problems. If you don't do this, it "works" until you realize the code is full of bugs, performs terribly, and can only be fixed with a rewrite.
[/quote]

[Edited at 2026-09-01 09:45 GMT]

Supervertaler Workbench is no longer actively developed | We are not Daisy...

lexica_nova — Fri, 28 Aug 2026 19:00:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: We are not Daisy...

and Daisy may not understand how dumb a job could be done when Claude is steered by a novice.

[quote]Dan Lucas wrote:

[quote]Li-Hsiang Hsu wrote:
I don't listen to what those people are saying anymore. They are just doing some tokenmaxxing, selling a product. That is consumer-facing storytelling, for people who don't know much about AI.[/quote]
Goodness me.

Well, I guess I could assume that this highly competent engineer at one of the world's top companies is lying - "storytelling" being a euphemism for this - and I suppose I could at the same time airily imply that only the smart people in the know really understand this, and that people who disagree with me are ignorant.

Alternatively, and in the absence of any evidence to the contrary, I could assume this engineer is telling the truth. But then again I grew up in a relatively high-trust society where we generally took people at their word.

Daisy straightforwardly acknowledges in a post on [url= [url removed] ]X.com[/url] that this is an expensive way to work and that she is privileged and lucky to be able to not have to worry about tokens.

At no point does she claim that every user necessarily has the resources to work in the same way. She is in effect giving us a glimpse of what the future might look like for the rest of us. The title of the section in the email is literally "How to Claude like Anthropic." What is misleading about that? Where is the lie?

Having said that, if the price of tokens declines at a similar rate to that of the price of semiconductors over the past forty or fifty years, that future may come to the masses more quickly than the cynics think. Certainly I have at my disposal today resources that I would not have foreseen even five years ago. What can I expect in twelve months? Probably more than the cynics think.

Dan
[/quote]

Supervertaler Workbench is no longer actively developed | Sure, let's assume the worst about people

Dan Lucas — Fri, 28 Aug 2026 18:54:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Dan Lucas
Post title: Sure, let's assume the worst about people

[quote]Li-Hsiang Hsu wrote:
I don't listen to what those people are saying anymore. They are just doing some tokenmaxxing, selling a product. That is consumer-facing storytelling, for people who don't know much about AI.[/quote]
Goodness me.

Well, I guess I could assume that this highly competent engineer at one of the world's top companies is lying - "storytelling" being a euphemism for this - and I suppose I could at the same time airily imply that only the smart people in the know really understand this, and that people who disagree with me are ignorant.

Alternatively, and in the absence of any evidence to the contrary, I could assume this engineer is telling the truth. But then again I grew up in a relatively high-trust society where we generally took people at their word.

Daisy straightforwardly acknowledges in a post on [url= [url removed] ]X.com[/url] that this is an expensive way to work and that she is privileged and lucky to be able to not have to worry about tokens.

At no point does she claim that every user necessarily has the resources to work in the same way. She is in effect giving us a glimpse of what the future might look like for the rest of us. The title of the section in the email is literally "How to Claude like Anthropic." What is misleading about that? Where is the lie?

Having said that, if the price of tokens declines at a similar rate to that of the price of semiconductors over the past forty or fifty years, that future may come to the masses more quickly than the cynics think. Certainly I have at my disposal today resources that I would not have foreseen even five years ago. What can I expect in twelve months? Probably more than the cynics think.

Dan

Supervertaler Workbench is no longer actively developed | Andrew Ng's small lesson on AI Engineering skills

lexica_nova — Fri, 28 Aug 2026 18:31:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: Andrew Ng's small lesson on AI Engineering skills

For those who are instereted in AI enginerring, I invite you to read this post:
[url removed]

And I quote:
[quote]A novice who vibe codes without understanding software fundamentals can create simple applications, but this often leads to the coding agent making bad tradeoffs in latency, availability, consistency, reliability, maintainability, simplicity, and/or cost. In such cases, the developer didn’t know such tradeoffs even existed and therefore did not steer the agent to make the right decisions for their application context.[/quote]

Supervertaler Workbench is no longer actively developed | Daisy is selling a product, and what she said is called "storytelling"

lexica_nova — Fri, 28 Aug 2026 18:08:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: Daisy is selling a product, and what she said is called "storytelling"

[quote]Dan Lucas wrote:

[quote]Li-Hsiang Hsu wrote:
And software engineers actually don't vibe code now. They are moving to complex multi-agent work.[/quote]
I agree with this, but even twelve months ago people would probably have said - with a slight sneer in their voice - that the workflow described by Daisy in a recent email from Anthropic (below) was vibe coding. Of course, in her case, this "vibe coding" is being performed by somebody who clearly knows a great deal about both coding and AI!

Maybe the whole "vibe coding" label is becoming increasingly meaningless and people will pay less attention to AI-driven tools and more about the underlying ability of the developer using them. After all, that is the way it has been for decades.

Dan

Daisy's workflow:

"My daily driver currently looks like: two lead agents that keep each other accountable and restart the other if either fails. These delegate to tech lead or PM agents for the 8-10 projects I'm running at any one time, and each project has 5-10 IC agents, generalists or specialists depending on the problem. Across all of these I'm still only doing 30-50 prompts per day, and my IC agents typically work autonomously for 2-3 days. About 60% of my interaction is with the leads, 35% with a project lead, and 5% is when something has gone off the rails. All of these agents communicate directly with the SendMessage tool."
[/quote]

I don't listen to what those people are saying anymore. They are just doing some tokenmaxxing, selling a product. That is consumer-facing storytelling, for people who don't know much about AI. Among developers, that’s another story. They won’t tell us a catastrophic story when their agents fail. That could be billions of tokens thrown out the window, a loss of a few thousand dollars. They won't tell us how often their agents fail. You have to read the benchmarks and test the agents yourself. And to do that, you must have that knowledge and that skill, a priori.
When I review Claude or its peers' code, I am really worried. Claude is very capable… most of the time, or maybe 80% of the time. That means its performance is not absolute. And when Claude doesn’t deliver what it should have done, you have to know. And preferably, take precautions to ensure that this does not happen. People who don’t know system design, or know little about software engineering, won’t be able to push Claude to do a great job.
In fact, LLMs are not trained to go the extra mile without you pushing them, without you knowing how to push them and constrain them. They are trained to do just “good enough” things based on your instructions. So their performance relies strongly on you: your preparations, your instructions, your guidance, your rules. And all that depends on your knowledge of that specific subject. Even if you are a very skilled developer, you can't be 100% sure that it does the required job every time. You need to have the means to monitor it, test the results, build metrics to test its output, and make corrections.
I won’t deny that Claude and its peers are very capable, increasingly so and most of the time. But saying that people who don't know much about a subject (i.e., amateurs) can make them do a great job, is certainly a lie - or, at the very least, a form of storytelling.

Supervertaler Workbench is no longer actively developed | Arguably "vibe coding" is no longer a meaningful label, if it ever was

Dan Lucas — Fri, 28 Aug 2026 16:58:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Dan Lucas
Post title: Arguably "vibe coding" is no longer a meaningful label, if it ever was

[quote]Li-Hsiang Hsu wrote:
And software engineers actually don't vibe code now. They are moving to complex multi-agent work.[/quote]
I agree with this, but even twelve months ago people would probably have said - with a slight sneer in their voice - that the workflow described by Daisy in a recent email from Anthropic (below) was vibe coding. Of course, in her case, this "vibe coding" is being performed by somebody who clearly knows a great deal about both coding and AI!

Maybe the whole "vibe coding" label is becoming increasingly meaningless and people will pay less attention to AI-driven tools and more about the underlying ability of the developer using them. After all, that is the way it has been for decades.

Dan

Daisy's workflow:

"My daily driver currently looks like: two lead agents that keep each other accountable and restart the other if either fails. These delegate to tech lead or PM agents for the 8-10 projects I'm running at any one time, and each project has 5-10 IC agents, generalists or specialists depending on the problem. Across all of these I'm still only doing 30-50 prompts per day, and my IC agents typically work autonomously for 2-3 days. About 60% of my interaction is with the leads, 35% with a project lead, and 5% is when something has gone off the rails. All of these agents communicate directly with the SendMessage tool."

Supervertaler Workbench is no longer actively developed | Technical/Cogntitive debts in software building

lexica_nova — Fri, 28 Aug 2026 13:38:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: Technical/Cogntitive debts in software building

The real issue, I believe, is not vibe coding per se or agent looping/graph engineering. And software engineers actually don't vibe code now. They are moving to complex multi-agent work.

But the real problem is whether the person creating the software/or having the software developed by agents understands what is built or what the agents have done. This is what is known as cognitive or technical debt subject. Basically, the more cognitive/technical debts you have regarding the software you created, the less you understand and have control over that, the less robust the software will be.

Supervertaler Workbench is no longer actively developed | I reviewed the code

lexica_nova — Fri, 28 Aug 2026 13:18:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: I reviewed the code

[quote]Dan Lucas wrote:

[quote]Li-Hsiang Hsu wrote:
Poor design and poor spec do lead to bad Claude performance.[/quote]
That's what I just said - IF you follow some variant of SDD properly you should be fine. But we have no evidence that Michael has been guilty of not designing properly. So his code should be OK.

Your earlier comment implied that code generated by earlier generations of frontier LLMs isn't good enough. I don't agree. I think for the past eighteen months at least it has been (more than) sufficient for the kind of development that we are doing here.

I'm equally sure that there are fields of endeavor where LLMs just will not cut it, but here we are basically messing around with text processing. It is, literally, not rocket science.

Dan [/quote]

What I said isn't based on the software being "vibe-coded," but rather on my use experience, my impression after reading the code and getting an overview of its architecture. At least from an architectural standpoint, the code Claude wrote has a lot of room for improvement - and I was referring to this specific piece of software, Supervertaler Workbench. I don't mean to say that everything is bad, but it is just not robuste.

And yes, I happen to know well Python. I wouldn't have been able to read the code if the software was written in Java.

Supervertaler Workbench is no longer actively developed | Er, yes

Dan Lucas — Fri, 28 Aug 2026 13:07:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Dan Lucas
Post title: Er, yes

[quote]Li-Hsiang Hsu wrote:
Poor design and poor spec do lead to bad Claude performance.[/quote]
That's what I just said - IF you follow some variant of SDD properly you should be fine. But we have no evidence that Michael has been guilty of not designing properly. So his code should be OK.

Your earlier comment implied that code generated by earlier generations of frontier LLMs isn't good enough. I don't agree. I think for the past eighteen months at least it has been (more than) sufficient for the kind of development that we are doing here.

I'm equally sure that there are fields of endeavor where LLMs just will not cut it, but here we are basically messing around with text processing. It is, literally, not rocket science.

Dan

Supervertaler Workbench is no longer actively developed | endnotes/footnotes, , among others.

lexica_nova — Fri, 28 Aug 2026 13:04:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: lexica_nova
Post title: endnotes/footnotes, , among others.

[quote]CafeTran Trainer wrote:

[quote]Michael Beijer wrote:

The reason why I decided to include Okapi is that Supervertaler Workbench could then make use of its extensive file filters, rather than have to code them from scratch in Python. [/quote]

That makes sense, Michael. But then again, how many filters do you really need? Usually, just the one for your next project! 😄

Python actually has very mature libraries for formats like MS Word (.docx), so you rarely have to build anything from scratch. The main advantage of sticking with pure Python is control and simplicity. Following the K.I.S.S. principle, I personally prefer to keep the stack fully Python-based whenever possible.

And for those rare cases where Python cannot parse an exotic file format, I import the files into Trados and do a round-trip via SDLXLIFF.

[/quote]

I now need to switch from python-docx to lxml to parse docx documents from OOXML. Python libraries don't handle this.

Supervertaler Workbench is no longer actively developed | As many as I can get my hands on!

Michael Beijer — Fri, 28 Aug 2026 12:52:00 +0000

Forum: Supervertaler
Topic: Supervertaler Workbench is no longer actively developed
Poster: Michael Beijer
Post title: As many as I can get my hands on!

[quote]CafeTran Trainer wrote:

[quote]Michael Beijer wrote:

The reason why I decided to include Okapi is that Supervertaler Workbench could then make use of its extensive file filters, rather than have to code them from scratch in Python. [/quote]

That makes sense, Michael. But then again, how many filters do you really need? Usually, just the one for your next project! 😄

Python actually has very mature libraries for formats like MS Word (.docx), so you rarely have to build anything from scratch. The main advantage of sticking with pure Python is control and simplicity. Following the K.I.S.S. principle, I personally prefer to keep the stack fully Python-based whenever possible.

And for those rare cases where Python cannot parse an exotic file format, I import the files into Trados and do a round-trip via SDLXLIFF.

[/quote]

Ha ha, how many file filters do I need? As many as I can get my hands on! It seems that almost daily a client will send me some yet another gigantic, multi-file job in a file format that pushes even Trados/memoQ to their limits. I don't think there is any realistic way to handle all these edge cases in Python alone. It's a fun challenge, but on a daily basis, I just need to get all these jobs done and out the door and ensure my client will receive them in the correct format. I can rely on Trados Studio to handle pretty much anything they throw at me.