bigbezet

The CSS debugger "trick" is really bad advice. CSS borders affect the layout and can break things. Use an outline instead.

It's not a desktop tool, it's a CLI tool.

But a lot of desktop tools are written in JS because it's easy to create multi-platform applications.

A lot of devs, including me, have tried something similar already. I don't really find this approach reliable.

Firstly, tools like Claude Code already have things like auto memory.

Secondly, I think we all learned by now that agents will not always reliably follow instructions in the AGENTS.md file, especially as the size of the context increases. If we want to guarantee that something happens, we should use hooks.

There are already solutions to track what the agent did and even summarising it without affecting the context window of the agent. Tools like Claude Code log activity in a way which is possible to analyze, so you can use tools to process that.

When I tried something similar in the past, the agent would not really understand what is important to "memorise" in a KNOWLEDGE.md file, and would create a lot of bloat which I would then need to clean up anyway.

There are existing tools to tell the agent what has happened recently: git. By looking at the commit messages and list of changed files, the agent usually gets most of the information it needs. If there are any very important decisions or learnings which are necessary for the agent to understand more, they should be written down >manually< by a developer, as I don't trust the agent to decide that.

Also, there is an ongoing discussion about whether AGENTS.md files are even needed, or whether they should be kept to an absolute minimum. Despite what we all initially thought, those files can actually negatively affect the output, based on recent research.

I don't think having the server render the table HTML and you injecting it is a good idea. You rely on the server returning valid HTML. What if the server has downtime, and returns a 200 response but with a "maintenance mode" page, or something similar? Having it render only on a successful response and correct parsing of JSON data is more reliable. You also start complicating things in terms of separation of concerns. You potentially have to adapt any styling considerations in your API, for instance if the table needs a class adding to it. Overall, not a good idea, imho.

This is a bit of a non-article. It barely makes any point, and I'm not even sure who the target audience is.

> But encryption may not be silver bullet we often treat it as. An encryption algorithm like AES doesn’t know if the file it’s concealing holds a wedding photo, a recipe, or a list of all your passwords.

How's that a bad thing?