haizzz

Hey HN, we built Bulwark (https://getbulwark.ai) because the current permission model for coding agents doesn't scale. Having to constantly check back in to approve or reject commands defeats the purpose. One agent, one terminal, one human watching is fine, but to get the most out of these agents, we need to run multiple sessions across laptops, servers, and cloud dev environments with the same permission set.

Bulwark is a centralized permission layer for coding agents. Define a single set of policies that are enforced across all sessions and devices, approve uncommon commands from a single dashboard with a full audit trail. Let your agents run at full speed and be confident that they won't wreak havoc on your machines and integrations!

Works with Claude Code and Amp now, with more integrations coming.

Reviewing agents PR in a vibe coding era still feels a bit heavy. Skim allows you to "vibe review" your PRs, focusing on changes to concepts and logic rather than individual lines

Separately we also found that git lfs is not very optimised for large repositories, notably its locking feature which list every file tracked by git for every checkout and commit command.

To clarify here, "generated" and "autogenerated" were bad choices of words. They're translations created by humans and is dependent on the strings in code.

See also: https://news.ycombinator.com/item?id=37318052

Yup, we switched over to using the built in monitoring daemon and it's much less hassle!

The translations are dependent on the original strings that is in code. For example if we change "design anything" to "design everything", the translations also needs to be updated to reflect that and by keeping it within vcs, we have an atomic change including both code, copy and translation. Moving it to a database would make updates easier but would now be a separate process to "sync" between copy change in code and translation changes in the database

Author here, the phrase "generated" was the wrong choice of word here. These translations are manually translated by humans in another systems and consolidated into these .xlf files so they're dependent on what the original strings are in code at a specific commit. They cannot be generated on the fly

Hi Hacker News, Tidbits is a project that I had been working on to filter through clickbait news articles, sensational headlines and low impact articles. With large language models gaining popularity, this project outsource the filtering process and send notification for articles that are newsworthy. There had been a few similar posts in recent days and it's great to see this issue being solved by others as well. I had been a big fan of Sip by Product Hunt before it was shutdown and wanted to recreate a similar experience!

Sip: https://www.producthunt.com/stories/sunsetting-sip-a-post-mo...

Not quite, the .messages.ts and Message.java files are only in English which are then converted into XLIFF files for other languages so they're the source of truth for what the string should be in different locales so they're not cache

author here, xlf files are translations that are coupled with the texts we set in the code so they're not really generated I admit that was misleading. What I wanted to get across is they're not touched directly by engineers but they're still created through our translation pipeline where real humans translate them

Author here, not everyone on the team works on git and git performance. Our team work on a variety of things that touch "code" in general like our ownership system and tooling, access control, bots and automation, etc...

Sorry I've been a bit misleading. These xlf files aren't generated, they're just not interacted with by engineers but they're still created and edited by humans as translations. We want to keep track of them so that if we deploy a different commit, the texts and translations in other languages will match

I made another comment as well though tldr is these xlf files are translations tied to texts in code so we can't simply ignore them from the repository. The changes have to be kept so that if we say revert to a certain commit, all the translations match with the texts of headers, buttons, etc...

hey hey author here, xlf files are translations that are coupled with the texts we set in the code so they're not really generated I admit that was misleading. What I wanted to get across is they're not touched directly by engineers but they're still created through our translation pipeline where real humans translate them

Hey everyone, author here, the article is a bit misleading in that .xlf files aren't really generated files, they're created through our translation pipeline by real humans. I considered them generated in the sense that they're not directly worked on by engineers who have to deal with them in the repository.

The content of these translation files are snapshot in time aligned with the text in our product so simply removing them we would lose all the changes made to translations each time texts are changed.

Sorry about that, hope this clears it up!

Edit: for more information on translation and xlf files, we have another blog post all about them https://canvatechblog.com/how-to-design-in-every-language-at...