jannesblobel

That fits perfectly with the idea that everything should actually be in the repository. At last, I no longer have to update the images myself. Thanks!

Absolutely, it's also cool to see that so much is happening here right now. Sometimes you need a bit of a network to get something like this off the ground. Building infrastructure is never easy.

Imagine shipping a product, and a few weeks later, you see Thomas Dohmke raise $60M for almost the exact same idea.

Some weeks ago we launched this:

https://github.com/Legit-Control/monorepo/tree/main/examples...

The idea was simple: keep AI prompts, intents, and conversations alongside your code and commits — basically treating AI interaction as first-class development artifacts. everything just plain Git

We struggled to get momentum. Things happen.

Now, less than 24 hours ago, Thomas announced Entire.io:

“Entire CLI hooks into your git workflow to capture AI agent sessions on every push. Sessions are indexed alongside commits, a searchable record of how code was written.”

That’s… very, very close to what we tried to build.

Honestly, I love the vision and think this will matter a lot in the AI age. It’s validating to see someone with that reach betting big on it.

Best of luck to Thomas and the team behind Entire.

It’s surprising how fast you can design real interfaces with Pencil.dev already. The workflow feels closer to writing code than pushing pixels, quick iterations, clear diffs, and no heavy UI getting in the way.

What really stands out is that everything lives in Git. Designs sit next to the code they relate to, with versioning, history, and collaboration handled by tools developers already use. This avoids a lot of the friction Figma had for years, where design history, branching, and reviews were either missing or awkwardly bolted on later.

If Sketch -> Figma was about moving design to the browser, Pencil feels like the next step: treating design as a first-class, versioned artifact in the developer workflow.

Curious how designers and engineers here think about Git-based design workflows, and where this approach might fall short compared to Figma.

As a developer tool, it seems fairly obvious to have Git integration so API collections can be versioned and reviewed like code.

I was surprised this wasn’t already supported. Does anyone know what made this difficult, or why it took this long to ship?

Perhaps I should add something here. It always depends on the task. Claude with SUDO access doesn't seem right to me either, but I wouldn't run that anywhere else either.

If your system were under version control, so that Claude could do whatever it wanted on its own branch, so to speak, would it still be such a big problem? Because you could just roll back if it really did cause problems, couldn't you?

Thanks, glad you like the Legit.

On expanding beyond Claude: there’s no concrete plan right now since we built this around Claude, but we’re very open to it. If you have a preferred CLI (e.g., Codex, OpenCode, or something else), feel free to open an issue in the repo. Or just describe your use case here and I will do it :)

Regarding branches: the tool does not pollute your working branch. Each session lives on a separate “session” branch that contains all prompts and operations. Your normal working branch stays clean.

When you end a session, you’re prompted to either:

merge the code changes into your working branch, or

discard them.

If the video or README didn’t make this clear enough, I’d appreciate the feedback I’ll update the docs accordingly.

how can I change the QR code?

A current concern of mine, also when using Claude Cowork, is that I don’t want files to be modified if I can’t control their versions/ if they aren’t versioned at all.

And even though it doesn’t actually get full sudo access, giving an LLM permission to edit files without being able to track exactly what it’s doing still feels risky.

I wanted to try it out, but unfortunately I can't open the document/I don't know how to create a new one.

I didn't mean to complain at all. It was just an observation I wanted to share. I didn't know that HN did that.

That's exactly why I'm not upgrading. This Liquid Glass UI looks so ugly...

Please excuse the late reply; notifications at HN could be significantly better.

For example, for writing a blog post, if I only want to write down notes, meeting notes, etc.

Nice project! I’m always interested in new note‑takers because I haven’t found one that really fits my workflow yet.

As @_mig5 mentioned, having version control with history tracking would be amazing — and an agent mode could be really cool too.

thanks, this game made my team and me 20 min unproductive in a meeting :D

Just by reading through all the comments and input under that post — “I know that I know nothing.” — Socrates

A lot of the comments and input here make sense. I’ll follow your advice and observe HN for a while, looking for interesting topics that suit me.

> You know what I was not interested in? The git history.

Sure, that makes sense, if you’re just interested in the internals, the history doesn’t matter. I get that.

But what do you think about the idea of keeping two views of history? One that’s clean and human-readable, and another that preserves all the detailed commits. With the right filters, you could switch between the simple view and the full story.

EDIT: By the way, I just want to discuss a theory/some thoughts here. There are always pros and cons, and perhaps my text is a little too harshly worded.

Think of a refactor where you tried one approach, rolled it back, then found the right fix. If you squash, all those failures vanish. With full history, an AI (or future you) can see the dead ends and spot patterns. I think that’s what Augment Code is doing with their Context Lineage idea: indexing the messy history so tools can explain how code evolved.

https://www.augmentcode.com/blog/announcing-context-lineage

TLDR: i18n is more than just using translation tools; it requires collaboration among developers, translators, and designers. Developers need good DX tools, translators need TMS or CAT tools, and designers need translation visibility in Figma. Proper i18n is a continuous process and should be integrated from the beginning to avoid major issues.

Disclaimer: I have a connection to one of these companies, just want to share some knowledge. I strive to be as neutral as possible.

Fun fact: I'm German and know the challenges with the UI. It's a love/hate relationship!

The problem with i18n (internationalization) is that many developers and product owners believe it’s only about implementing a library and letting Google Translate, DeepL, or even ChatGPT do the rest. As most of you already know, that approach doesn't work well for German speakers. My language will break/destroy your UI design.

The real issue with i18n is that it involves many stakeholders throughout the process. Here are the most important ones to start with:

Developers: These folks need to implement a library and want a good DX (Developer Experience). It means You should choose a library with an IDE extension (e.g., VS Code's Sherlock i18n, i18n Ally). - Libraries: Please use something that utilizes .json files. Formats like .po are cumbersome and will cause many issues. - Use tooling that supports an ecosystem around it, like lint rules, to save time and effort.

Translators: Ideally, your preferred solution includes a TMS (Translation Management System) or a CAT (Computer-Assisted Translation) tool.

Designers: If your designers can't see the translations in tools like Figma, your UI will break, and users will complain. Figma plugins like Parrot, Phrase, or Weblate can help (just search for 'i18n' in Figma's marketplace).

All the apps mentioned are just a few examples among many tools available.

Conclusion: The important stakeholders in this process are Developers, Translators, and Designers. i18n is an ongoing process, not a one-time task. If you start your app or project with i18n from the beginning, the annoying parts are manageable, and it won’t cost you all your nerves.

Why do I ask myself that? I was at the Merge Berlin Conf at the weekend and had a few conversations about the fact that the ambitions are far too big anyway. But doesn't it make a lot of sense to build a web sdk with build in version control? If not, what am I missing here?

It's ridiculous that we can land a rocket like a helicopter in 10 square meters, but there is still no decent document editor that gives me all the features of a version control system. I'm sitting on the train and must write a document to my colleague. Have you ever traveled with Deutsche Bahn? You can forget about the internet, so Google Docs is out. Well, writing Markdown and using a Git host and so on is out, too, because my colleague is unable to write Markdown. I really hope that Lix will be ready soon so that we can build a decent Docs editor and finally get VSC functions. Please excuse me if this sounds very harsh. But it is really annoying.

Why did you choose sveltekit-i18n instead of another svelte i18n lib?