With every new model, I check how good it is. I like to test it on different tasks.
This time Opus 5.5 did a great job. We planned the whole app together. Then I went to enjoy a wine festival in Prague while Claude kept working.

The app

The idea behind it was simple. What if we had a super fast local app that could handle big files and also connect to machine translation and AI? I’m not a big fan of keeping production files locally, but sometimes you have to review something locally or edit a huge file.

After one weekend, here’s what the app can do today:

• open XLIFF and TMX files (the bilingual files translators work with), and TBX glossaries for reference.
  One XLIFF with 1 million segments opens in about 2 seconds. A big XLIFF and TMX together in about 10 seconds. Search is fast too!

• run 30+ deterministic checks: missing tags, numbers, extra spaces, target same as source and so on

• spellcheck

• compare an old and an updated file to see the changes

• show matches from translation memories, machine translation and a glossary

• AI review - you can use an API key or your own Claude Code or Codex subscription

• you don’t need a mouse. Everything works with keyboard shortcuts

• All panels are resizable and you can move them around, so the app looks exactly the way you like to work

How I worked with it

I sent around 40 messages. A lot of them were short.

We started with planning. It asked questions and I answered. When the plan was ready, I approved it and Claude started working. I gave it time frames: 2 hours, 6 hours, one night. Every run ended with a report, and I tested the app in between.

In total Claude worked about 30 hours. The longest run without me was almost 7 hours. It used about 13 million tokens and read 1.3 billion from cache, all on my Claude subscription.

My part was knowing which features are actually needed. Things like “Fix all tags” (the formatting codes inside the text) in one click, or an inconsistency check across several files.

What I think about Opus 5.5

It’s just great. Sure, there were some bugs, and some things didn’t work as well as I thought, so I had to change the idea along the way. But overall I’m very happy with the results.

Opus 5.5 really feels like a model that’s good enough on its own, and you don’t need any other. It can create different things from scratch, and improve things it couldn’t before.

Claude also redesigned my website

On Monday I also asked if it could redesign my website. A few rounds later I picked a design I liked, and now it's live at sebastiandziecielski.com.

What’s next

More experiments. :) What I’m testing next:

• more Opus 5.5, starting with workflows in the app: one key that runs pre-translate, checks, AI review and save

• Hermes Agent. I’ve started running it on a small server, where a cheap model does a few jobs for me already. It’s a long-term project for sure

• some local models. Can a smaller model give similar quality to bigger models like Claude? We will see

I’ll share what I find here.

If you want a second pair of eyes on your setup, or want me to test something like this on your files: hello@sebastiandziecielski.com

Last year a lot of the people and companies I talk to tried building their own “translation platform”. Most of them have stopped and realized it’s not the right strategy.

I’m sure for some companies it makes sense. But for a lot of them it really doesn’t. From what I see, even big AI companies buy their translation tools and services from translation/platform companies. You would think they have the tokens to build their own, but they choose to just buy one.

I understand why people started doing it. Some of these platforms are super expensive, and with claude or codex, you can get a working MVP quite fast.

AI coding is great, but for larger systems it might not be as cheap as you think. Time and tokens are going to be the most expensive part here.

So here are the three options I think we all have.

Option 1: Build your own

Pros:

• You can create something that is custom-made and fits your organization. You stop paying for features you never use.

• A simple MVP can be created super fast now.

Cons:

• It is not a weekend project. You need far more than you expect: vendor management, project management, connectors, a translation editor and a long list of translation features you don’t even know your PMs and translators need.

• In its first year it will not be as good as a proper TMS.

• Somebody has to maintain it for years.

The companies that struggle the most usually have good engineers, but not much translation experience. They assumed connecting AI was the whole job. It was just the beginning, while their local teams weren’t happy with the quality, and AI translation on its own wasn’t good enough.

But the biggest cost, in my opinion, is that it’s a distraction. You spend a year on something that, even if it works, leaves you where you started: with a translation platform that you already had anyway. Your processes haven’t changed, and that’s where you should have looked first. But you were distracted by a shiny new thing.

Who should build their own? Start with the reason (or “Start with Why”, if you will :) ). Build when there is something missing that you need day to day. If you can’t name that thing, don’t build.

Then the team. You need technical people who understand what they are replacing and what they are trying to improve, who know translation, and who plan to look after it for years. Those teams exist, but might be hard to find.

Option 2: Keep the translation platform you are already paying for and automate the rest

Pros:

• You build automation that helps you run production and saves you way more time.

• If it stops being useful over time, it’s not a problem. You can just stop using it whenever you want.

Cons:

• You keep paying the TMS subscription.

• You are limited by what the platform lets you do from the outside.

One example. After translators deliver, somebody should check the files: numbers, placeholders, glossary terms. In practice a PM did it by hand for every language, or it was skipped. So I built a check that runs on its own after every delivery, runs around forty checks and messages the team only when it finds something serious. Nobody has to remember to do it.

Other automation you could build or set up:

• the regular checks a project manager does by hand

• task creation

• reporting/data

• QA and testing

• connecting your systems

• i18n work

• context for translation

Option 3: Switch to another translation platform, then automate

Pros:

• Another platform may fit your stack better and/or cost less.

• Moving the data (your TMs, glossaries, etc.) is easier than it used to be, thanks to AI and better infrastructure.

Cons:

• It can still take anywhere from one month to a few months, depending on company size and whether you also have to develop new connectors, etc.

• Moving data isn’t the issue. Onboarding new vendor and people is, and no tool speeds that up much.

• If your processes aren’t fixed, a new platform is not going to fix them for you.

What I’d do

Personally, I think it’s better to buy a translation platform that suits you best (options 2 and 3) and automate the rest.

With coding agents, building your own platform is tempting, but in my opinion focusing on internationalization, context for translators, data and automation is the better choice right now. Sure, that might change in a couple of years, and it really depends on the company.

It’s not only about translation. You have the same choice for a CRM, an ERP, or any other system your company has. Build around it first.

If something in your localization team gets done by hand every week, start there.

This is the work I do. If you want a second pair of eyes on your setup: hello@sebastiandziecielski.com